Design Discussion (offtopic from Fav Petitions)

HonoredMule wrote: I'm pretty keen on prepared statements myself.  I'm of a mind that if the front-end team can't be trusted to systematically handle SQL safely, they're probably going to create even bigger security holes via arbitrary code execution, which can include SQL anyway--and the restrictions just increase the back-and-forth/red tape, slowing development.  But if I were working with a larger team on larger deployments (i.e. the front and back end teams are actually separate entities as opposed to the same person or team of 3 people), I'd disable non-stored-procedure queries on the back end too.

Heh, not worried about the front-end teams code; just like to be in the stituation where if the web servers security is breached you still can't affect much

Obviously, it depends on the situation. If its an internal or closed user group business app then direct SQL isn't such a problem.

lol.

I admire your fatalistic optimism.

GM Stormcrow wrote: GM ThunderClap wrote: I may slip some .NET into the db when SC's not looking (Shhh...); but mainly just for things SQLServer is bad at: email, raw file i/o etc - naturally kicked off into an asynchronous thread to keep up the linear execution speed of the procs. But we don't talk about that A witch! Burn him!

You don't look like a newt

GM Stormcrow wrote: GM ThunderClap wrote: I may slip some .NET into the db when SC's not looking (Shhh...); but mainly just for things SQLServer is bad at: email, raw file i/o etc - naturally kicked off into an asynchronous thread to keep up the linear execution speed of the procs. But we don't talk about that A witch! Burn him!

Sounds like a strong kind of magic!

Right.  What I'm meaning to say is that you have far more capacity to control what can be done by an authorized entity (i.e. the webserver) than you would more typically.  There's clearly a lot that is done to carry out game progress and comparatively very little the website needs to be allowed to do.  CRM software, for example must be able to access and arbitrarily modify so much sensitive information, and do so much with it interactively (such as charging credit cards or reversing charges) that compromising the CRM itself is about as serious a security leak as one can have, regardless of how tightly DB access from the webserver is controlled.

Of course that's where good software should ideally be splitting the front end into an actual front end and a middle tier for business logic and some more dynamic/heuristic security checks.  At least then you can, for example, keep full credit card numbers away from the web server, though it must still be allowed to do things with the credit card numbers it can't see.

In practice, I've never actually seen a proper 3-tier web-based project.  To be honest, the stuff I've seen in the wild kind of scares me.  But like I mentioned earlier, the clientele for which I was indirectly working was a bit seedy, and a hard sell for security improvements that require a rewrite for existing architecture that just plain sucks.  One already takes his chances, I guess, when dealing with telemarketers or borderline-fraudulent web services (like sites selling access to casting calls that were just scraped from other sites like craigslist).  Just don't be surprised if having a hard time canceling your account isn't your only grief.

I'd love to find a similar shop but working on more respectable projects.  My coworkers and boss were awesome, but their business associations less so.

I absolutely love the hat, by the way.  It's impossible to find a decent bowler hat around here that fits my narrow head.  So I wear a soft fedora instead.


Edited by HonoredMule - 25 Mar 2010 at 00:26