I disagree, you seem to have missed MY point, which is that if you have issues as wide ranging in an application as improper input sanitizing, you aren't going to fix it by simply limiting where the attacks occur, you are just changing what is going to be attacked. I don't disagree that a least privilege system is a good idea, but it is impractical at best for most Web Applications. Perhaps not the dinky scripts some people write to track their contacts or what have you. Horde is a good example of the large type of Web Application I am discussing.
Originally posted here by catch
chsh, again for the point of arguing with me you've missed the point.
The flaw in that statement is we are discussing an environment with ONE application. There is no Application Y here, and application X NEEDS to be able to write to directory Z. What you are discussing is Functionality X of Application A doesn't need to update a database, while Functionality Y of Application A does need to update a database. The differences are minute but rather critical.
That is all RBAC/Least privilege ever does. If application X cannot write to directory Z, but application Y can... does this mean there is no point in making application X not be able to?
It isn't difficult for me to understand, I was making it clear for everyone else (since you failed to do so) that it would fall apart in large scale applications. That's all.
One more time, repeat after me... this is a "shoestring tutorial." It doesn't deal with huge databases or issues of dramatic scalability. It was just intended to present a concept. Why is that so difficult for you? Beside, the table can/most likely would use a plain text row for simple administrative identification and indexing.
I'd like to see proof in the form of patches, number of lines changed before I believe you can just drop in such changes on an already built app in less than a half an hour. If you've done it, that shouldn't be a problem. Otherwise, you're just talking out your ass.
First off, this technique can be applied to something like PHP-nuke in less than half an hour, and perhaps even faster if a module was developed. As far as I can tell, there is no faster/cheaper way to more or less universally reduce the risk of SQL Injection attacks.
Interesting twist of my words, but sorry, not going to respond to crap I didn't say.
Hmm, well pretty much all web applications and all applications in general are in need of redevelopment, least they are likely to suffer a security problem in the future.
So I guess any patch could be considered "a convoluted half-cocked concept hack that might help in specific circumstances." Is this to mean that you are against patching, even patching like this that resolve known and unknown attacks preemptively? Everything should just be rewritten at the first sign of trouble?
Perfect in regards to security? A couple. It is possible you know, contrary to the ultra paranoid concept everyone wants to believe. Within the scope of your application, you can make things perfectly secure. If this weren't the case, how come QMail has never been broken (drawing on an industry example)?
Read above, or are you suggesting that every other security type is moot? because you know, if every application was perfect, there would be no need for security. How many perfect applications have you created?
Funny thing here, you're worried about people stealing your data, what about people doing damage to the data? Dropping a production database is a bad thing, small or large. Basically what you have stated is that your system is superior from the standpoint of security, but if people can break into your user management system from Script A, and on mine they can't do it because there's PROPER INPUT VALIDATION, how does that make yours more secure than mine?
How is this different than on a system with data sanitation? In my system, unless the attacker has access to each users password, the user account management system is useless to them. And thanks to least privilege only one, very small script would have access of any kind other than SELECT to the user database. Unlike your approach where all the scripts retain this access.
Actually, if you read what I wrote instead of making your own assumptions about what I'm going to write, you might realise that's pretty far from the case.
The problem here is that you suffer from the flawed assumption that the best way to security is to prevent all exploits. This is, at best impractical (especially when using third party software), the goal of security should then be to minimalize the effects of a given exploit to reduce the damage it can inflict.
All I gotta say is, you started this thread with:
I do not wish to argue this point with you further, if you have more to say on the subject please direct your responses to TPEP@gibraltar.ncsc.mil, I am sure they would love to hear how you feel that 40 years of their efforts on computer security are flawed because they don't focus on preventing exploits from occurring.
And I think it's rather clear that that is STILL the case. I have brought real world, business arguments against your concepts and you have failed to defend them, and are now refusing to do so.
People have criticized me for not making real world arguments... they say every system I discuss is for high security, high assurance, high budget, with intelligent users. I must be honest, that is the majority of my experience and this has always been a stumbling block when posting here or searching for work.
I have nothing against granular access controls, but as they apply to many web applications, it is highly impractical, and you are FAR better served by doing things properly in the first place. Proper input filtering, stored procedures, and prepared statements are all examples of things that can help you achieve what you are trying to do with multiple users in the proper manner.