WebApp Sec mailing list archives
Re: Prevent security bypass
From: Chris Travers <chris () travelamericas com>
Date: Wed, 05 Feb 2003 23:19:42 -0800
Adam wrote:
What makes you say that? If you are on NT, then any insecurities of the authentication protocol are ALREADY going to affect you. Applying diversity in depth might buy you something but only if it is paired with good NT security practices, Besides, if your server is not secure, you are already screwed.It depends how secure you want it as a lot of people have said but I would personally go for what you suggested as bar the v.expensive suggestions or the ones relying on being on the same NT network you arent going to get anything very secure. We have a secuirty script called on each secure page. The overhead doesnt seem that bad tbh.
The way I design my web applications which require granularity of permissions for different users or other advanced security features is based on the following principles:
1) Primary Security on Backend-- don't try to do any more enforcement than you have to on the middleware. And avoid ANY enforcement of anything important on the front-end. Instead, try to do as much enforcement with the backend components as possible and only suppliment with the middleware as needed. The idea here is that you enforce permissions using the web server, operating system, and/or information store (such as RDBMS and LDAP) as much as possible because these are the most robust security-wise, and they can be attacked independently anyway. Furthermore these are the only solutions that can globally protect the information (from inside the web context or outside it).
2) Supplimental Security in Middleware-- Sometimes, it is necessary to place information in the information store in an insecure fassion,and this could be used for DoS attacks. One example might be a user profile in an RDBMS system where all users will be able to write to and update that table. In this case, enforce additional security on the middle-ware. But this security is much more brittle and not as strong, so it should not be relied upon as much.
3) Protect content In Transport-- Use SSL to protect the content and passwords.
Best Wishes, Chris
Current thread:
- Prevent security bypass Chris Neil (Feb 04)
- Re: Prevent security bypass Kalyan Varma (Feb 04)
- Re: Prevent security bypass Igor Guarisma (Feb 05)
- RE: Prevent security bypass Adam (Feb 05)
- Re: Prevent security bypass Chris Travers (Feb 06)
- RE: Prevent security bypass Adam (Feb 06)
- RE: Prevent security bypass Larry Seltzer (Feb 06)
- Re: Prevent security bypass Chris Travers (Feb 06)
- Re: Prevent security bypass Chris Travers (Feb 06)
- Re: Prevent security bypass Ulrich P. (Feb 05)
- Re: Prevent security bypass Chris Travers (Feb 04)
- Re: Prevent security bypass c3rb3r (Feb 04)
- Re: Prevent security bypass Adrian Wiesmann (Feb 04)
- Re: Prevent security bypass sunzi (Feb 07)
- Re: Prevent security bypass Ernie Nelson (Feb 07)
- HTTP Header and POST Data Exploitation Rahul Chander Kashyap (Feb 08)
- Re: Prevent security bypass Ernie Nelson (Feb 07)