Web Application Security


Published on

Short presentation on web application security.

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Web Application Security

  1. 1. Web Application Security A web developer's perspective on the issues and challenges of web application development
  2. 2. Web Application Security <ul><li>Web application security is a complex topic, a product of current technology as of current situations.   </li></ul><ul><li>Web application security involves the developers who create web applications, the attackers and vulnerabilities they exploit. </li></ul><ul><li>This presentation will cover:  </li></ul><ul><ul><li>Web Developer's World </li></ul></ul><ul><ul><li>Web Attacker's World </li></ul></ul><ul><ul><li>Web Application Attacks </li></ul></ul><ul><ul><li>  Recent Attacks </li></ul></ul>
  3. 3. Web Developer's World  
  4. 4. Web Developer's World <ul><li>Web developers face many issues on a daily basis: </li></ul><ul><ul><li>A web developer is expected to be: </li></ul></ul><ul><ul><ul><li>Developer for </li></ul></ul></ul><ul><ul><ul><ul><li>Client (JavaScript, Flash, etc) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Server (PHP, Coldfusion, Perl, Ruby, etc) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Database (SQL, MySQL, etc) </li></ul></ul></ul></ul><ul><ul><ul><li>Designer / Artist </li></ul></ul></ul><ul><ul><ul><ul><li>Graphics </li></ul></ul></ul></ul><ul><ul><ul><ul><li>HTML/CSS </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Flash </li></ul></ul></ul></ul>
  5. 5. Web Developer's World <ul><ul><li>Web developers are expected to support: </li></ul></ul><ul><ul><ul><li>Legacy platform support </li></ul></ul></ul><ul><ul><ul><ul><li>Old browsers (IE 6) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Old code </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Client security configurations </li></ul></ul></ul></ul><ul><ul><ul><li>Bleeding edge configurations </li></ul></ul></ul><ul><ul><ul><ul><li>Latest browsers </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Latest plug-ins </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Latest buzz-word based development priorities </li></ul></ul></ul></ul><ul><ul><li>Security Standards? </li></ul></ul><ul><ul><ul><li>No commonly accepted standards </li></ul></ul></ul><ul><ul><ul><li>Low priority on secure development </li></ul></ul></ul>
  6. 6. Web Developer's Wold <ul><li>So many issues require prioritization and simplification. </li></ul><ul><li>  </li></ul><ul><li>There is not enough time in the day for most web developers to create an application which fits the customer's needs and is very secure. </li></ul><ul><li>The use of frameworks and libraries speeds development but also provides an increased opportunity for an attacker to prepare. </li></ul>
  7. 7. Web Attacker's World  
  8. 8. Web Attacker's World <ul><li>Web Attackers have exceptional expertise in web development, often beyond typical web developers. </li></ul><ul><li>  </li></ul><ul><li>The nature of web application languages allow the study of functionality and aid in exploitation. </li></ul><ul><li>Lack of security tools for web applications make exploitation simple and detection difficult. </li></ul><ul><li>  </li></ul><ul><li>If an attacker is patient and motivated enough, they will find a way to exploit a web application. </li></ul>
  9. 9. Web Attacker's World <ul><li>There are many kinds of people who attack web pages. They can be divided into groups by goals and methods. </li></ul><ul><ul><li>Malware Distribution: </li></ul></ul><ul><ul><ul><li>Goal: Expose client computers to malware. </li></ul></ul></ul><ul><ul><ul><li>Methods: JavaScript Injection, XSS, File Upload. </li></ul></ul></ul><ul><ul><li>Data Theft:  </li></ul></ul><ul><ul><ul><li>Goal: Access data, usually for financial gain. </li></ul></ul></ul><ul><ul><ul><li>Methods: SQL Injection, XSS, Compromised Client. </li></ul></ul></ul><ul><ul><li>Hacker: </li></ul></ul><ul><ul><ul><li>Goal:&quot;Own&quot; server for other purposes. </li></ul></ul></ul><ul><ul><ul><li>Methods: SQL Injection, File Upload. </li></ul></ul></ul>
  10. 10. Web Attacker's World <ul><li>These groups of attackers can also be grouped by the amount of overall damage their actions have to the web host itself: </li></ul><ul><ul><li>Malware Distribution: </li></ul></ul><ul><ul><ul><li>Malware exposure is a temporary embarrassment for many hosts. </li></ul></ul></ul><ul><ul><li>Data Theft:  </li></ul></ul><ul><ul><ul><li>Stolen data has legal ramifications for both the host and thief. </li></ul></ul></ul><ul><ul><li>Hacker: </li></ul></ul><ul><ul><ul><li>Completely hacked servers are often ransomed or sold as well as the data they contain. </li></ul></ul></ul>
  11. 11. Web Application Attacks  
  12. 12. Attacks: Session Hijacking <ul><li>When users are logged into web applications, unique sessions are created to hold their temporary data. </li></ul><ul><li>A session might contain the user's account information, including credit card account or other sensitive data. </li></ul><ul><li>If a session's unique id is exposed, then it could be used to bypass authentication while the session is not expired by the server. </li></ul><ul><li>Long session timeouts on a server with session information in the URL make the information vulnerable to exploitation. </li></ul>
  13. 13. Attacks: Session Hijacking <ul><li>For example:  </li></ul><ul><li>     Very weak session security would allows an attacker to capture the urls a coffee shop customer is visting.  The attacker then retrieves the session id from the captured traffic and visits the same sites as the user with the captured session id.  The attacker would then be accepted by the sites as the previous user. </li></ul><ul><li>To avoid session hijacking: </li></ul><ul><ul><li>Never let the session id be written into the URL of the browser. </li></ul></ul><ul><ul><li>Expire sessions as soon as possible. </li></ul></ul>
  14. 14. Attacks: URL Restriction Failure <ul><li>A web application usually begins when a user requests the default page from a URL, such as a user requesting &quot;http://www.company.com&quot;.  Company.com might return &quot;index.php&quot; which starts the user's interaction with the web application. </li></ul><ul><li>The flow of the web application, one page linking to another, follows a path determined by the web developer. </li></ul><ul><li>Some pages are intended for the user to access, and others are not.  If pages not intended for the user are not properly secured, they can benefit an attacker. </li></ul>
  15. 15. Attacks: URL Restriction Failure <ul><li>If &quot;index.php&quot; is inteded for a user, but &quot;admin.php&quot; is not, the developer might try to hide this page from unauthorized users. </li></ul><ul><li>The developer might do nothing and hope no one stumbles upon the page (security though obscurity). </li></ul><ul><li>The developer might decide to hide the page from search engines by adding the page to the &quot;robots.txt&quot; for the site.  But the &quot;robots.txt&quot; is readable by anyone and a enticement for an attacker.  </li></ul>
  16. 16. Attack: URL Restriction Failure <ul><li>Robots.txt Example:  </li></ul><ul><li>  </li></ul><ul><li>User-Agent: * </li></ul><ul><li>Disallow: /admin.php </li></ul><ul><li>Disallow: /secret </li></ul><ul><li>Disallow: /dbadmin.php </li></ul><ul><li>Disallow: /upload.php </li></ul>
  17. 17. Attacks: URL Restriction Failure <ul><li>Web applications can accept and pass information in the URL. </li></ul><ul><li>For example:  </li></ul><ul><li>domain.com/adm.php?a=add&u=bob&email=bob%40aol.com </li></ul><ul><li>With the example, any user requesting that URL might add the user &quot;bob&quot; with the email address of &quot;bob@aol.com&quot;. </li></ul><ul><li>  </li></ul><ul><li>If the web application is based upon a common framework or tool, the attacker can look at open source code for vulnerabilities which can be exploited via the URL without logging in. </li></ul>
  18. 18. Attacks:Cross Site Request Forgery (CSRF) <ul><li>A CSRF is like a URL Restriction Vulnerability, actions can be triggered via a URL request.  In a more secure configuration, authentication and a session are required for the URL request to be acted upon. </li></ul><ul><li>In CSRF, the attacker targets users who have active sessions on vulnerable web pages and tricks them to make the URL request. </li></ul><ul><li>For example: </li></ul><ul><li>    A bank web page user is logged in while reading an email asking them to click the following link: </li></ul><ul><li>  https://bank.com/transfer.php?amnt=4000.00&account=1234 </li></ul>
  19. 19. Attacks: Injection Attacks <ul><li>Any data passed to a server is vulnerable to mainipulation. </li></ul><ul><li>  </li></ul><ul><li>Manipulated data can allow a server or client to be compromised. </li></ul><ul><li>If an attacker can inject JavaScript or HTML, then client computers viewing the page can be manipulated. </li></ul><ul><li>If an attacker can inject SQL, the database server is at risk. </li></ul><ul><li>If an attacker can inject server code (php, perl, etc) then the web server itself is at risk. </li></ul>
  20. 20. Attacks: Injection Attacks <ul><li>To allow a injection attack, specific conditions must exist: </li></ul><ul><ul><li>HTML Forms must lack validation on at least the server side.  Client-side validation is better for user interaction but can be bypassed very easily. </li></ul></ul><ul><ul><li>Variables inserted into server code in SQL statements must also lack validation. </li></ul></ul><ul><ul><li>Web server functions to evaluate variables as code without validation allow server code injections (php, perl, etc). </li></ul></ul><ul><li>  </li></ul><ul><li>To protect from an injection attack, trust no data a user can supply.  Validate before using any data and white-lists are better than black-lists. </li></ul>
  21. 21. Attacks: XSS Attack <ul><li>XSS attacks are specifically crafted injection attacks. </li></ul><ul><li>A XSS attack allows an attacker to alter the functionality of a web application. </li></ul><ul><li>  </li></ul><ul><li>A XSS attack can: </li></ul><ul><ul><li>Redirect a user to a phishing web page. </li></ul></ul><ul><ul><li>Hijack a user's account and perform actions such as spread malware links, send messages or even transfer money. </li></ul></ul>
  22. 22. Attacks: XSS Attack <ul><li>XSS Attacks can be persistent (stored) and non-persistent (reflected). </li></ul><ul><li>A Persistent XSS might be a script automatically executed when a web application user's profile page is shown.  The Persistent XSS script would have been inserted by an attacker in the profile creation process. </li></ul><ul><li>A Reflected XSS attack might be in the form of a hyperlink sent in an email to a user.  The hyperlink might take the user to a legitimate site, but the site itself loads a malware script due to extra information in the URL. </li></ul>
  23. 23. Recent Attacks <ul><li>ONS Brazil Power Grid Operator  </li></ul><ul><li>(http://bit.ly/BrazilPowerHack) </li></ul><ul><li>  </li></ul><ul><li>Effect: Administrative web page compromised but did not effect power operations. </li></ul><ul><li>Method:  </li></ul><ul><li>1. Robots.txt exposed locations of internal-use web pages. </li></ul><ul><li>2. Exposed web pages were vulnerable to injection (login page username field not validated). </li></ul><ul><li>3. SQL Injection resulted in data exposure of account information to control web applications. </li></ul>
  24. 24. Recent Attacks <ul><li>Forta.com, HouseOfFusion.com </li></ul><ul><li>(http://bit.ly/GalleonCFHack) </li></ul><ul><li>Effect: Total server compromise </li></ul><ul><li>Method: </li></ul><ul><li>1. File upload for forum avatar image, executable CFML code was uploaded. </li></ul><ul><li>2. While file is uploaded filename and location are predicted and repeatedly requested, before server was able to validate and delete the CFML file. </li></ul><ul><li>3. On the CFML file access by client, malicious code is copied and downloaded to server. </li></ul>
  25. 25. Recent Attacks <ul><li>Wordpress 2.8.3 Blogs </li></ul><ul><li>(http://bit.ly/wordpress283hack) </li></ul><ul><li>Effect: Reset of admin account password to unknown value. </li></ul><ul><li>Method: </li></ul><ul><li>1. Attacker browses to  </li></ul><ul><li>        http://domain.com/wp-login.php?action=rp&key[] </li></ul><ul><li>2. Admin account password is reset to random string with no confirmation email. </li></ul>
  26. 26. Questions?  
  27. 27. Additional Resources <ul><li>OWASP Top 10 </li></ul><ul><li>http://bit.ly/owaspTop10 </li></ul><ul><li>Insecure Web Apps </li></ul><ul><li>http://bit.ly/insecureWebApps </li></ul>