Web Programming Step by Step

Lecture 24
Web Security

Except where otherwise noted, the contents of this presentation are Copyright 2010 Marty Stepp, Jessica Miller, and Kevin Wallace.

CSE <= 190M

• until now, we have assumed:
  • valid user input
  • non-malicious users
  • nothing will ever go wrong
• this is unrealistic!

The real world

• in order to write secure code, we must assume:
  • invalid input
  • evil users
  • incompetent users
  • everybody is out to get you
  • botnets, hackers, script kiddies, KGB, etc. are out there
• trust nothing

HTML injection

a flaw where a user is able to inject arbitrary HTML content into your page

• This flaw often exists when a page accepts user input and inserts it bare into the page.
• example: magic 8-ball
  • https://webster.cs.washington.edu/stepp/security/8ball.html
  • What kinds of silly or malicious content can we inject into the page? Why is this bad?

Injecting HTML content

8ball.php?question=<blink>lololol</blink>

• injected content can lead to:
  • annoyance / confusion
  • damage to data on the server
  • exposure of private data on the server
  • financial gain/loss
  • end of the human race as we know it
• why is HTML injection bad? It allows others to:
  • disrupt the flow/layout of your site
  • put words into your mouth
  • possibly run malicious code on your users' computers

Cross-site scripting

a flaw where a user is able to inject and execute arbitrary JavaScript code in your page

8ball.php?question=<script type='text/javascript>alert('pwned');</script>

• JavaScript is often able to be injected because of a previous HTML injection
• example: Lab 4 (Buy-a-Grade)
  • https://webster.cs.washington.edu/stepp/security/buyagrade.html
  • How can we inject JavaScript code into the page? Why is this bad?
• injected script code can:
  • masquerade as the original page and trick the user into entering sensitive data
  • steal the user's cookies
  • masquerade as the user and submit data on their behalf (submit forms, click buttons, etc.)
  • ...

Securing against HTML injection

• one idea: disallow harmful characters
  • HTML injection is impossible without < >
  • can strip those characters from input, or reject the entire request if they are present
• better idea: allow them, but escape them

$text = "<p>hi 2 u & me</p>";
$text = htmlspecialchars($text);   # "&lt;p&gt;hi 2 u &amp; me&lt;/p&gt;"

SQL injection

a flaw where the user is able to inject arbitrary SQL commands into your query

• This flaw often exists when a page accepts user input and inserts it bare into the query.
• example: simpsons grade lookup
  • https://webster.cs.washington.edu/stepp/security/grades.html
  • What kinds of SQL can we inject into the query? Why is this bad?

A SQL injection attack

• The query in the Simpsons PHP code is:

  $query = "SELECT * FROM users
  WHERE username = '$username' AND password = '$password'";
  

• Are there malicious values for the user name and password that we could enter?
• Password:
• This causes the query to be executed as:

  $query = "SELECT * FROM users
  WHERE username = '$username' AND password = '' OR '1'='1'";
  

  • What will the above query return? Why is this bad?

Too true...

• injected SQL can:
  • change the query to output others' data (revealing private information)
  • insert a query to modify existing data (increase bank account balance)
  • delete existing data (; DROP TABLE students; -- )
  • bloat the query to slow down the server (JOIN a JOIN b JOIN c ... )
  • ...

Securing against SQL injection

• similar to securing against HTML injection, escape the string before you include it in your query

$username = mysql_real_escape_string($_REQUEST["username"]);
$password = mysql_real_escape_string($_REQUEST["password"]);
$query = "SELECT name, ssn, dob FROM users
WHERE username = '$username' AND password = '$password'";

• replaces ' with \', etc.
• you must log in to the db using mysql_connect before calling mysql_real_escape_string