WebApp Sec mailing list archives
RE: Current Project Design, Comments?
From: alex () netWindows org
Date: Tue, 18 Mar 2003 14:05:51 -0500 (EST)
On Tue, 18 Mar 2003, Vitor Ventura wrote:
I am currently on a project designing an ASP.NET-based application for a client. I would welcome any comments on my security design so far.
Don't run beta code. Why .NET? What sold you on it from a security standpoint that was more compelling than the argument that it's totally new code that is not yet tested (and hasn't seen the standard Microsoft "third try's a charm" treatment)? Do the benefits of .NET in your environment outweigh the risks? (that's something only you and/or your client can answer)
Communication Protection ------------------------ Client Web Browser to Web Server: 128-bit SSL encryption Web Server to Database Server: IPSec (via Windows 2000 Server)
The encryption means a lot less than what you do with your keys. Who signed your keys? Are they actually checked in any meaningful way when you setup a connection? How do you store them? etc... As Prof. Spafford once said: "Using encryption on the Internet is the equilvant of arranging an armored car to deliver credit card information from someone living in a cardboard box to someone living on a park bench." it's who/what you've got on the ends of those connections that matters. Are they Win2K boxen? If so, do you know how to properly secure them? If not, go back to Square One, do not pass go, do not collect $200.
Authentication -------------- Client to Web Server: Custom authentication against a username/password stored in Oracle DB. The database actually only stores the username, a hash of the password, and a random salt value used in the hashing process. No password is actually stored in the database.
What kind of password strength are you enforcing? What about rotation? Is password changing allowed? Is it required? Enforced?
Web Server to Database Server: A single identity is used to talk to the DB server from the Web Server. These credentials are stored on the Web Server in encrypted form and are decrypted when needed (and stored in memory). The key for decryption is the password of the web account - this is all handles via Window's data protection api.
Since the DPAPI relies on the strength of this password for it's saftey, is this a strong password? Have you run LOpht Crack on the box/account? How about the ACL's on that users's homedir? (it's where the "Master Key" for the DPAPI is stored by default). Is this password rotated? Are password strength requirements enforced in an ongoing manner?
Authorization ------------- Client to Web Server: Subsystems of the application are protected via custom role-based security. Each user has a "role" and if that page is not viewable by that role, they are redirected to a different page.
Is this the same error page as if the resource does not exist at all? If not, you've got an information disclosure problem.
Web Server to Database Server: The trusted identity has minimum rights to the specified tables and procedures needed to perform its duties.
Have you verified that all triggers for those tables can affect only those tables? Is that user allowed to load new PL/SQL or Java Stored Procedures after deployment?
Pretty standard in the web world, correct?
Yep, sounds like you've got a good start on it. Depending on your/your client's security requirements, a code review (preferably by people that know what they're doing) could be in order. Also, what you've outlined says nothing about many of the more critical security and information design decisions you probably made over the course of the project. Such as, is critical customer data both readable and writeable by the same systems? What kind of perimiter defenses do you have in front of those chewy Windows boxen? Are tasks and privledges broken out correctly? I could go on for days = ) Without a much fuller description of the goals, requirements, and design of the system, we can only make vague recommendations that ammount to band-aids. My advice is to contract with a security person to assess your risk if it's really a requirement for you. HTH.
Current thread:
- RE: Current Project Design, Comments?, (continued)
- RE: Current Project Design, Comments? Logan F.D. Greenlee (Feb 14)
- RE: Current Project Design, Comments? Michael Loll (Feb 14)
- RE: Current Project Design, Comments? Tim Aranki (Feb 14)
- RE: Current Project Design, Comments? Scott (Feb 14)
- RE: Current Project Design, Comments? Gal Rozov (Feb 17)
- RE: Current Project Design, Comments? Michael Loll (Feb 17)
- RE: Current Project Design, Comments? TUER, DON (Feb 17)
- RE: Current Project Design, Comments? Douglas Schlenker (Feb 17)
- RE: Current Project Design, Comments? Sarbjit Singh Gill (Mar 03)
- RE: Current Project Design, Comments? Vitor Ventura (Mar 18)
- RE: Current Project Design, Comments? alex (Mar 18)