Web_Security_Programming_II

Security Design Principles
Except where otherwise noted all portions of this work are Copyright (c) 2007 Google and are licensed under the Creative Commons Attribution 3.0 License /licenses/by/3.0/
Security Design Principles
• • • • • • • Least Privilege Defense in Depth Secure Weakest Link Fail-safe Stance Secure By Default Simplicity Usability
Principle of Least Privilege
Usability
• Users typically do not read documentation (Therefers can be lazy (Assume: They ignore security dialogs) • Secure by default features in software forces users and vendors to be secure.
“Good Enough” Security
Design for security by incorporating “hooks” and other low-effort functionality from the beginning. This way, you can add more security as needed without having to resort to work-arounds.
Simplicity
• Complex software is likely to have security holes (i.e. sendmail). • Use choke points – keep security checks localized. • Less functionality = Less security exposure
Secure By Default
• Only enable the 20% of the products features that are used by 80% of the user population. • “Hardening” a system: All unnecessary services off by default • More features enabled -> more potential exploits -> less security!
What about this?
GET ../../../../etc/shadow HTTP/1.0
Defense in Depth
• Also called redundancy / diversity • Common world example: Banks • Passwords:
– Require users to choose “strong” passwords – Monitor web server logs for failed login attempts
“Good Enough” Security
• The fraction of time you spend designing for security in your application should be proportional to the number and types of threats that your software and business face • But remember: Customers expect privacy and security
How Can We Fix This?
/* if the requested file can be successfully opened and read, then return an OK response code and send the contents of the file */ osw.write ("HTTP/1.0 200 OK\n\n"); while (c != -1) { sb.append((char)c); c = fr.read(); } osw.write (sb.toString());
Security Features Do Not Imply Security
• Using one or more security algorithms/protocols will not solve all your problems!
– Using encryption doesn’t protect against weak passwords. – Using SSL in SimpleWebServer doesn’t protect against DoS attacks, access to /etc/shadow, etc.
Security Features Do Not Imply Security
• Security features may be able to protect against specific threats • But if the software has bugs, is unreliable, does not cover all possible corner cases: The system may not be secure despite the security features it has
SimpleWebServer and “Elevated Privileges”
• Suppose a system administrator were to run SimpleWebServer under the root account • When clients access the web server, they can access all the files on the system! • Maybe we can control this by not storing sensitive documents in the web server’s directory tree…
An “Infinite” File
• The Linux /dev/random is a file that returns random bits (often used to generate cryptographic keys) • It can be used as a source of infinite data.. • What happens when the web server receives: GET //dev/random HTTP/1.0
Fail-Safe Stance
• Common world example: Elevators • System failure should be expected (and planned for)
– If firewall fails, let no traffic in – Deny access by default
Source
• The content of these slides was adapted from:
• "Foundations of Security: What Every Programmer Needs To Know" (ISBN 1590597842) by Neil Daswani, Christoph Kern, and Anita Kesavan. • /ntk
• Just enough authority to get the job done. • Common world example: Valet Keys • A web server should only be given access to the set of HTML files that the web server is to serve.
SimpleWebServer and Fail-Safe
• serveFile()
/* if the requested file can be successfully opened and read, then return an OK response code and send the contents of the file */ osw.write ("HTTP/1.0 200 OK\n\n"); while (c != -1) { sb.append((char)c); c = fr.read(); } osw.write (sb.toString());
Secure the Weakest Link
• Common Weak Links:
– Unsecured Dial-In Hosts; War Dialers – Weak Passwords; Crack – People; Social Engineering Attacks – Buffer Overflows
And Don’t Reinvent the Wheel!
• SimpleWebServer has many security vulnerabilities… • Building a secure, high-performance web server is a very challenging task • Apache: