Your SlideShare is downloading. ×
Web  Security  Programming  I I
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Web Security Programming I I

131
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
131
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • There are many specific security practices, but they all flow from a small set of well-accepted principles. We’ll go through each in detail.
  • The first principle, the principle of least privilege, states that to ensure security in a system, a process should only be given access to the most limited set of resources necessary to accomplish its task. That is, a user or a computer program should only be given just enough authority to get his or her or its job done. A common every-day example of the principle of least privilege at work in the physical world is the use of valet keys. A valet is someone that parks your car for you when you arrive at a hotel or restaurant, and people give their car keys to valets so that they can do so. Most cars that you buy these days come with special valet keys, and valets are given valet keys to park cars. The valet key allows to valet to only start the car and drive it to its parking spot. The valet key does not give the valet access to open the glove compartment or the trunk, where valuables might be kept. The idea is to give the valet access to only those resources necessary to do his or her job of parking the car. If we were to attempt to design a valet key system for an automobile even better, we might limit the number of miles that could be driven with the valet key! Similarly, we should follow the same principle when designing our computer programs. If a web server is responsible for serving files to web users, the web server should only be given access to the set of HTML files that the web server is to serve. By following this approach, if the web server is broken into, and the attacker is able to access a command shell, the most that the attacker would be able to do is read the HTML files. An example of how attackers can infiltrate a system that does not correctly take advantage of the principle of least privilege is bad set-uid scripts. On UNIX systems, sometimes it is necessary to elevate the privilege of a process. For example, when a user wants to change her password, the “passwd” program that is used to do this must make changes to the system password file once it authenticates the user. The only user that typically has access to modify this file that contains all of the usernames and passwords of all the users in the system is the administrator. But in order for the passwd program to work, the passwd program itself must be given administrator privileges to change the password for the user’s account once the user is authenticated. The passwd program is said to have its uid, or user id, set to root (the administrator account) when it runs. That is, regardless of which user runs the passwd program, the program is executed with elevated privileges (that of root instead of the regular user) to do its job. While the passwd program is an example of a program that absolutely must be set-uid to root to get its job done, there are examples of other UNIX programs that had a set-uid to root that didn’t absolutely need this privilege. These programs violate the principle of least privilege and lead to security vulnerabilities. For example, old version of the “lpr” command in the UNIX system was used to print files, and could be told to delete a file after it was printed. The old version of this command used to be set-uid to root because the file would need to be copied to a special “print spool” directory owned by root. So, it was possible to abuse “lpr” to delete other people’s files. The way this would work is you provide the name of some other users file to lpr and you also tell it do delete the file. Since lpr runs with root privileges, it copies the file into the print spool directory, and then deletes it. The root account is allowed to delete any file, and so it does not matter that you may not be authorized to delete the other person’s file– when you run lpr, you are given elevated root privileges, and are allowed to do anything that lpr will let you. Had the principle of least privilege been followed in the original design of the lpr command, the command would not be set-uid to root. Instead, a separate user account would have been created for the express purpose of printing files. The print spool directory would be owned by that account. The lpr command would be rewritten such that it would execute in two sub-processes. Sub-process 1 would be set-uid to the print-spool account and copy the file to be printed into the print spool directory, and sub-process 2 would be the traditional rm command that only allows a user to delete his or her own file. Least privilege can minimize the damage that can result from an attack by a trojan horse.
  • Root account gives the system admin complete access to all aspects of a system.
  • Due to the way the FileReader constructor works, it will attempt to access the file specified by the string argument relative to the current working directory. The attacker can traverse up the directory tree to the root directory and then access etc/shadow which contains a list of all usernames and passwords. How do we fix this in the code? We need to validate pathnames that are sent in a GET request…
  • Banks: security guards (guns), bulletproof glass, cash with dye, …
  • Fail-safe: even if one or more components of a system fail, there is still some level of security. If elevator power fails, they grip their cables by default. Let’s say that you are developing a client for a system that sends a password to an authentication server to check the password. If the authentication server is down, access by all clients should be denied by default
  • This is a fail-safe approach: If an attacker can force the web server to run out of memory, it crashes, but it does not do something insecure such as skipping an access control check or serving any document requested. Even though this is a fail-safe approach, forcing the web server to run out of memory can result in DoS attack.
  • SimpleWebServer will continuously read data from /dev/random/ until the web server runs out of memory and crashes.
  • Check the file length of the requested file and if it is below a pre-defined max (some percentage of available memory), serve the file, else error. Problem: /dev/random is a special file: f.length() returns 0 since it does not actually exist on disk Don’t store the file in memory – just stream the bytes incrementally. Again, /dev/random would tie up the server forever with the one request. No other clients would be serviced. (this is not multi-threaded) Don’t store in memory, and impose a download limit: this will work… Only send MAX_DOWNLOAD_LIMIT bytes to the client before stopping. This deals with the /dev/random issue, but if a client requests a large file, it might get cut off in the middle of a download resulting in file corruption.
  • For example, Windows traditionally ships with many (network) services on by default (i.e, IIS!). Vulnerabilities become available to attackers immediately after the system is installed and set up! To prevent this, create a “hardened” version of your system, and new installations should be made based on the “hardened” version.
  • A choke point is a centralized piece of code through which control must pass.
  • User’s don’t know what they need: stock quote example: users might say that they just want their quotes fast and don’t want them to be encrypted (i.e., since the information is public anyway), but a bad guy might change the content and force people to do trades they wouldn’t want to do otherwise since few people will actually double check the stock quote info.
  • S ecure S ockets L ayer: The leading security protocol on the Internet. Developed by Netscape, SSL is widely used to do two things: to validate the identity of a Web site and to create an encrypted connection for sending credit card and other personal data. Look for a lock icon at the bottom of your browser when you order merchandise on the Web. If the lock is closed, you are on a secure SSL or TLS connection
  • Transcript

    • 1. 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 http://creativecommons.org/licenses/by/3.0/
    • 2. Security Design Principles
      • Least Privilege
      • Defense in Depth
      • Secure Weakest Link
      • Fail-safe Stance
      • Secure By Default
      • Simplicity
      • Usability
    • 3. Principle of Least Privilege
      • 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.
    • 4. 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…
    • 5. What about this?
      • GET ../../../../etc/shadow HTTP/1.0
    • 6. 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
    • 7. Secure the Weakest Link
      • Common Weak Links:
        • Unsecured Dial-In Hosts; War Dialers
        • Weak Passwords; Crack
        • People; Social Engineering Attacks
        • Buffer Overflows
    • 8. 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
    • 9. 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 ");
      • while (c != -1) {
      • sb.append((char)c);
      • c = fr.read();
      • }
      • osw.write (sb.toString());
    • 10. 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
    • 11. 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 ");
      • while (c != -1) {
      • sb.append((char)c);
      • c = fr.read();
      • }
      • osw.write (sb.toString());
    • 12. 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!
    • 13. Simplicity
      • Complex software is likely to have security holes (i.e. sendmail).
      • Use choke points – keep security checks localized.
      • Less functionality = Less security exposure
    • 14. Usability
      • Users typically do not read documentation (Therefore: Enable security by default)
      • Users can be lazy (Assume: They ignore security dialogs)
      • Secure by default features in software forces users and vendors to be secure.
    • 15. 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.
    • 16. 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
    • 17. “ 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
    • 18. “ 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.
    • 19. And Don’t Reinvent the Wheel!
      • SimpleWebServer has many security vulnerabilities…
      • Building a secure, high-performance web server is a very challenging task
      • Apache: www.apache.org
    • 20. 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.
      • http://www.learnsecurity.com/ntk