views:

7

answers:

0

I'm writing some db access server controls at the moment that take properties for things like data source and column required and whatnot.

In my head I have thought about this approach and it seems to me that, in order to make these controls work you have to put them on the page and fill them full of explicit references to the database at app design time. But what a client eventually sees is the rendered output, the underlying control system should be hidden from a user, right?

I've had a quick look about for articles pertaining to a scenario where you're writing a server control that references underlying bits of a db and the security approaches therein but I think my google fu was failing because the terms were general and popular. I got a lot about "sql injection" and a lot about "custom server controls" but precious little about both together.

Maybe I'm just being paranoid I'd like to know if someone's encountered such a scenario and, if so, any pointers or words of wisdom about security issues or gotchas with server controls that use ADO.Net?

I'm intending to do a bunch of testing on this stuff and take another view, trying to compromise the security of the page from the client end after the page has been served but unless I start throwing about the names of server objects in the page's GET or POST I can't see that there would be much of a problem, or surely there would be issues with the standard Data grids and whatnot.

Anyway, over to you.