CATION FLAWS

1. COMMON APPLI CATION FLAWS

2. Back To Basics Objective • Provide an overview of common application flaws • No ‘exploitation’ techniques • Discussion based, to provide an understanding • To provoke thinking • Originally going to provide a Tokemon walkthrough • Won’t work over conference call

3. OWASP Top Ten Summary Cross Site Scripting <script>alert()</script> Injection Flaws • SQL, LDAP, XML, etc File Execution • Scripting, RFI, shell execution Direct Object Reference • /access.asp?record=## Cross Site Request Forgery • Session riding, Accessing internal device

4. OWASP Top Ten Summary Information Leakage and Error Handling • Every bit of information helps an attacker Broken Authentication and Session Management • Login bypass, cookie manipulation Insecure Cryptographic Storage • Static keys, Non seeded encryption Insecure Communications • HTTP, Clear text internal web services Failure to Restrict URL Access • /adminportal/adminfunction?action=adduser&user=me

5. User Supplied Input Is The Cause Comes from many places • Passed on the URL, or as a parameter • Passed in posted data, hidden fields • Passed in HTTP headers, referer • Cookie data, client certificates, files for import, etc.. THE USER CAN NOT BE TRUSTED... EVER • Validate ALL user input, server side • Cint(), isDate(), len() <= x, isAlphaNumeric() • Whitelist, NOT blacklist • Decode input, in the correct order, and in the right case • Filter Output at use • Different uses of data, require different filters

6. Faulty Filters Worse Than No Filters function cleanrequest(theID) theID = lcase(theID) if instr(theID,";") > 0 then theID = left(theID,instr(theID,";")-1) end if if instr(theID,"exec ") > 0 then theID = left(theID,instr(theID,"exec ")-1) end if /page.aspx?theID=1;exec xp_cmdshell‘serverpwnage.exe’; Function To Filter User Input Looks For The Use Of A Semi Colon Looks For The Term exec followed by a space This Filter Can Be Bypassed By Using A Tab Character As A Separator /page.aspx?theID=1%09exec%09xp_cmdshell ‘serverpwnage.exe’;

7. Faulty Filters Worse Than No Filters function displayText(htmlInput) htmlInput=str_ireplace("script", "",htmlInput) echo htmlInput /page.php?htmlInput=<script>alert()</script> Function To Display User Input Looks For The Term script And Remove It Display The Filtered Data These Types Of Filters Are Just Rubbish! /page.php?htmlInput=<sscriptcript>alert()</sscriptcript>

8. The Clean Server Robots.txt / Sitemap.xml • Often reveal more than they should • Spiders don’t have to obey Things that don’t belong • Site archives • .svn trees • .inc, .cfg, .txt, bak, .backup • Admin portals • ‘hidden’ paths • Virtual sites Don’t Want It Indexed? Don’t Link It! Don’t Want It Found? Don’t Put It There http://www.owasp.org/_admin/ http://www.owasp.org/_database/ http://www.owasp.org/_debug/ http://www.owasp.org/_debuglogs/ http://www.owasp.org/_includes/ http://www.owasp.org/admin/ http://www.owasp.org/adminportal/ http://www.owasp.org/adminsite/ http://www.owasp.org/console/ http://www.owasp.org/backups/ http://www.owasp.org/logs/ http://www.owasp.org/admin/adminpage.jsp http://www.owasp.org/sysadmin/ http://www.owasp.org/sites/ http://www.owasp.org/admin/admin. http://www.owasp.org/admin/admin.asp http://www.owasp.org/admin/admin.bak http://www.owasp.org/admin/admin.inc http://www.owasp.org/admin/admin.log http://www.owasp.org/admin/admin.jsp http://www.owasp.org/admin/admin.php http://www.owasp.org/admin/adminpage. http://www.owasp.org/admin/adminpage.asp http://www.owasp.org/admin/adminpage.bak http://www.owasp.org/admin/adminpage.inc http://www.owasp.org/maintentance/ http://www.owasp.org/admin/adminpage.php

9. SQL Injection Manipulation of the SQL query string Becomes Or sqlString= select * from users where name =‘+userinput’+’and password=‘+userinput select * from users where name =‘admin’;--and password=‘anything’ select * from users where name =‘admin’ and password=‘anything’ or ‘1’=‘1’ Where (name =‘admin’) (and (password=‘anything’) or (‘1’=‘1’) ) Syntax Grouping Syntax Grouping

10. SQL Injection Use parameterized queries • asp, .net, java, php, python, flex? Use stored procedures • Type cast variables • Don’t use dynamic SQL inside procedure • Often seen in ‘search’ procedures • Use the QuoteName function DO NOT BUILD SQL STATEMENTS DYNAMICALLY Yes. Of course your flash application can be vulnerable to injection attacks SELECT @SQL = 'SELECT * from USERS WHERE NAME ='+ @Username EXEC @SQL

11. SQL Truncation Attacks Application vs SQL • The form data is stored varies between the two MySQL • MySQL will truncate data during an insert • PHP asks MYSQL “Any users by this name?” • MYSQL responds “No, I don’t know that person” • PHP says “Ok add a user by this name” • MYSQL says “Sure, his name is too long I’ll shorten it for you” User=“admin<100spaces>x” GEE THANKS

12. SQL Truncation Attacks MSSQL • Data is truncated when calling stored procedures • SQL returns record for admin • Data mailed to both admin and attacker User=“admin@site.com<100spaces>;attacker@home.com” Create procedure [FindUser] @username VARCHAR(100) ... Input To A Forgotten Password Page Parameter Has A Length 100

13. Databases Stored within the webroot • /dbase/dbase.mdb • Flat files etc.. Running as ROOT or SYSTEM • Or worse... A domain account Encryption Of Data • If the server or application is compromised, is the data? • Unique record ID of the user account • User supplied password Microsoft Used To Recommend This..... Don’t Use A Static Key Do Seed With User Specific Data

14. Cryptography Encryption is difficult • Do NOT roll your own XOR based encryption scheme • BASE64 is not encryption Weakness is in the implementation • Verify your data is getting encrypted • Use one way encryption for passwords Storing the secrets • Database credentials should never be stored clear text • Encryption keys should not be stored in accessible configs

15. Application Email Often vulnerable to spam attacks • SMTP is a text based protocol • CR/LF pairs and new command can be inserted Normal communication with SMTP server Mail From: <feedback@foo.co.nz> Rcpt To: <user@user.co.nz> Data Subject: This is a test email . quit

16. Application Email Injection through recipient field • user@user.co.nz>%0a%0drset%0a%0dMail From: <spam@foo..... Modified communication with SMTP server Mail From: <website@foo.co.nz> Rcpt To: <user@demo.co.nz> rset Mail From: <spam@foo.co.nz> Rcpt To: <newrecipient@host.co.nz> Data Subject: This is a spam email blah blah spam spam . quit RESET Injected New Details Injected

17. Cross Site Scripting The sending of user supplied input to the browser • More than alert() Reflective • Code passed as a parameter, usually on the URL Persistent • Code stored and then displayed to user Consequences • Cookie theft • Site interaction • Web application worms JavaScript is a powerful programming language

18. Cross Site Scripting Example flaw • echo “hello “.$_GET[‘username’].”welcome to the site” Normal output • <html>hello Brett welcome to the site</html> Exploit output • <html>hello <script>alert()</script> welcome ...</html> Widely Known, Well Explained, Still Exists In Most Applications Insert Any JavaScript Or Script Inclusion

19. CSRF Cross Site Request Forgery • Attacking site causes browser to make a request to target User logs into banking.co.nz • banking.co.nz sets an authentication cookie • User leaves but doesn’t log out User browses to attacking site • Attacking site creates a post to banking.co.nz • Users browser sends cookie with post • Browser is already authenticated

20. CSRF Defence • Each post must contain a random parameter value

21. Other Related Attacks Site redirection • User supplied input used as target page • Can be used in phishing and scam attacks Page inclusion • User supplied input use as source for frame, iframe, image Microsoft Still Do This In Versions Of OWA http://site.com/login.php?redirect=<value> <frameset> <frame src="topbar.html"> <frameset> <frame src="<%=request("page")%>"> </frameset> </frameset> External Content Displayed In Browser

22. Cookie Security This Sort Of Thing Still Happens! Don’t store credentials in the cookie • Set-cookie: user=admin Set the cookie path • Specifies which part of the application the cookie is sent to Requires Auth Cookie Set http://Application Secured Blog Posting Section http://Application/secure/login Insecure General Section http://Application/general/read If The Cookie Path Is Not Set A Vulnerability In The General Section Can Read The Secure Section Cookie

23. Cookie Security Set the SECURE flag • Prevents the cookie been sent in HTTP requests • Cookie sent even if target site not listening on HTTP Set the HTTPOnly Flag • Prevents access to the cookie through JavaScript • Defence against cross site scripting Attacker Needs Access To Sniff The Traffic

24. File Uploading File uploading is dangerous • Provides the ability for the user to create data on server • Usual attacks involve uploading a script file for access Check the file extension • Check the portion after the last . • Compare against WHITELIST Check the file data • Valid graphic, csv, numeric data Store as blob in database • Do NOT store as raw file under webroot Beware The NULL (%00) byte

25. File Include Attacks Local file include • Occurs when user can affect or supply a file path • Leads to disclosure of source and other sensitive items Remote file include • Occurs in PHP (usually), when an HTTP reference is provided • Is disabled in modern versions of PHP .NetLoadControl • Can be used to load arbitrary controls that exist on server If you must accept paths from a user • Reject anything that is suspect. Ie; ../../ ..\..\ %xx http://site.com/help.jsp?helppage=/help/index.html

26. Configuration What is wrong with these? <Limit GET> order deny,allow deny from all allow from 203.10.1.104 allow from 192.168.1.1 </Limit> <location path=“admin.aspx“> <system.web> <authorization> <deny users="?"/> </authorization> </system.web> </location> .htaccess Web.config

27. www.insomniasec.com