Web application security qa2010


Published on

Published in: Education
  • Be the first to comment

  • Be the first to like this

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

No notes for slide
  • Although the number of vulnerabilities affecting Web applications has grown at a staggering rate, the growth demonstrated in the first half of 2009 and continuing through the second half may indicate the start of a plateau, at least in standard (off-the-shelf) software applications for the Web. These figures do not include custom-developed Web applications or customized versions of these standard packages, which also introduce vulnerabilities.
  • The lecture is devided into two parts, a theoretical part and a practical part. We will begin with a few 101 and then go deep into the demos
  • A very Important restriction is that a JavaScript code origin from one domain could not see any data origin from a different domain. This restriction is called “Same Origin Policy” and was made to protect against a unwanted data sharing between two sites. Think of a scenario where an attacker creates a site with a script in it that “looks” at another browser’s window. The other window might contain the victim’s personal data (bank account details, for example). Same Origin Policy restricts the information coming from each domain to that domain only. Mainly, a script which is running on one domain cannot gain any data that comes from another domain.
  • Cross-Site Scripting is one of the most common security vulnerabilities. It happens when user input (such as HTTP params) is printed back to the response. When this is the case, an attacker can make a website to return an arbitrary JavaScript which may do malicious actions. One attack scenario would be to convince the victim to click on a link which exploits a vulnerable application
  • Let’s take a look at the chain of events during a XSS attack The attack creates and sends the victim a link to bank.com (a trusted site). The link contains a search string (or any other string that is echoed back), which contains a malicious JavaScript code The victim, clicks on this link, since he/she trusts the bank.com web site The bank.com web application, echoes back the malicious JavaScript code inside the response page. This JavaScript is executed in the security context of bank.com, since it is echoed by from that site. This means that it has access to DOM elements belonging to this domain/session The malicious script, sends the current cookie and session information, without the victim’s consent, to the evil.org web site, where the hacker is waiting for it.
  • If a hacker can get you to run a JavaScript, he/she can: - Steal your cookies for the domain you’re browsing - Completely modify the content of any page you see on this domain - Track every action you do in that browser from now on - Redirect you to a Phishing site - Exploit browser vulnerabilities to take over machine XSS is currently one of the “hottest” security risks
  • Web application security qa2010

    1. 1. Web Application Security What hackers are doing with your bugs Adi Sharabani IBM Rational Security Strategist IBM Master Inventor
    2. 2. About Me <ul><li>My name is Adi Sharabani </li></ul><ul><li>Security Strategist for IBM Rational </li></ul><ul><li>Used to manage the Rational Application Security Research </li></ul><ul><li>15 years of experience in Security </li></ul><ul><li>OWASP IL Committee </li></ul><ul><li>Application Security Insider Blog: http://blog.watchfire.com </li></ul><ul><li>Also, very proud to be a teacher in Ohel Shem, Ramat Gan </li></ul>
    3. 3. Web App Vulnerabilities Continue to Dominate <ul><ul><li>55% of all vulnerabilities are Web application vulnerabilities. </li></ul></ul><ul><ul><li>Cross-Site Scripting & SQL injection vulnerabilities continue to dominate. </li></ul></ul>
    4. 4. Agenda <ul><li>Theoretical part: </li></ul><ul><ul><li>Same Origin Policy </li></ul></ul><ul><ul><li>Cross-Site Scripting </li></ul></ul><ul><li>Practical part: </li></ul><ul><ul><li>Demonstrating a real attack </li></ul></ul>
    5. 5. Browser Scripting Capabilities <ul><li>What can scripts do: </li></ul><ul><ul><li>Scripts can perform user interactions with the site </li></ul></ul><ul><ul><li>Scripts can seamlessly interact with the web site </li></ul></ul><ul><ul><li>Can perform any action that is related to the site </li></ul></ul><ul><ul><li>Can launch signed and safe ActiveX control </li></ul></ul>
    6. 6. Scripting Restrictions – Same Origin Policy <ul><li>What scripts can not do: </li></ul><ul><ul><li>Scripts can only interact with the domain they came from </li></ul></ul><ul><ul><li>Scripts can see send and receive responses only from their own domain </li></ul></ul><ul><ul><li>Scripts can access other browser’s frames only from same domain </li></ul></ul><ul><ul><li>Scripts can issue requests to other domains (but cannot view the corresponding responses ) </li></ul></ul>a.com b.com a.com
    7. 7. XSS 101 <ul><li>XSS occurs when user input (JavaScript) is returned by the web application as is: </li></ul><ul><li>Simple exploit: </li></ul><ul><ul><li>http://www.thebank.site/action?param= <script>...</script> </li></ul></ul><ul><li>Result: </li></ul><ul><ul><li>Injected script returned by the server and executed by the victim’s browser </li></ul></ul><ul><li>XSS breaks Same-Origin Policy </li></ul><ul><ul><li>Vulnerable domain may now return arbitrary JavaScripts </li></ul></ul><ul><ul><li>String data = request.getParameter(“param”); </li></ul></ul><ul><ul><li>out.println(data) </li></ul></ul>
    8. 8. Cross Site Scripting – The Exploit Process Evil.org TheBank.site User Script returned, executed by browser 3 User sends script embedded as data 2 1 Link to bank.com sent to user via E-mail or HTTP
    9. 9. Exploiting XSS <ul><li>If I can get you to run my JavaScript, I can… </li></ul><ul><ul><li>Steal your cookies for the domain you’re browsing </li></ul></ul><ul><ul><li>Completely modify the content of any page you see on this domain </li></ul></ul><ul><ul><li>Track every action you do in that browser from now on </li></ul></ul><ul><ul><li>Redirect you to a Phishing site </li></ul></ul><ul><ul><li>Exploit browser vulnerabilities to take over your machine </li></ul></ul><ul><li>XSS is one of the Top Web Security Risk today (most exploited) </li></ul>
    10. 10. Demo
    11. 11. There are solutions for this! <ul><li>Education: </li></ul><ul><ul><li>Secure coding for developers </li></ul></ul><ul><ul><li>Security testing for QA </li></ul></ul><ul><li>Tools: </li></ul><ul><ul><li>Such as Rational AppScan (both blackbox and whitebox) </li></ul></ul><ul><li>Development process: </li></ul><ul><ul><li>Integration into the development lifecycle </li></ul></ul>
    12. 12. ? [email_address] http:// blog.watchfire.com