Application Security through a Hacker’s Eyes James Walden Northern Kentucky University waldenj@nku.edu

1. Application Security through a Hacker’s EyesJames WaldenNorthern Kentucky Universitywaldenj@nku.edu IMI Security Symposium

2. Why Do Hackers Target Web Apps? IMI Security Symposium

3. Attack Surface A system’s attack surface consists of all of the ways an adversary can enter the system. Merchant’s Bank Building IMI Security Symposium

4. Defender’s View of Attack Surface web server firewall wireless VPN IMI Security Symposium

5. Firewalls don’t protect Web Apps telnet Firewall ftp Application DatabaseServer WebClient WebServer Application HTTP Traffic Port 80 IMI Security Symposium

6. SSL won’t stop injection attacks, XSS telnet Firewall ftp Application WebClient DatabaseServer WebServer Application HTTPS Traffic Port 443 IMI Security Symposium

7. Revised View of Attack Surface external web apps external web server firewall VPN wireless database IMI Security Symposium

8. Intranet Security Assumptions Since the firewall protects you • Patches don’t have to be up to date. • Passwords don’t have to be strong. • There’s no need to be careful when you code. • There’s no need to audit your source code. • There’s no need to run penetration tests. But do your users have web browsers? IMI Security Symposium

9. Javascript Malware controls Clients Intranet Firewall telnet Group Server Main Server ftp WebServer (Javascript malware) WebClient HTTP Traffic Port 80 Wiki IMI Security Symposium

10. Java can see your real IP address behind NAT router. Javascript can scan your intranet behind NAT router. IMI Security Symposium

11. Sources of Javascript Malware • Evil web site owner inserts in page. • Attacker inserts malware into defaced page. • Attacker inserts malware into a public comment or forum post (stored XSS.) • Attacker creates link that causes web site to echo malware to user (reflected XSS.) IMI Security Symposium

12. external web apps external web server internal web apps firewall VPN internal web servers wireless database Re-revised View of Attack Surface IMI Security Symposium

13. Web Applications external web apps external web server internal web apps firewall VPN internal web servers wireless database IMI Security Symposium

14. Web Application Vulnerabilities Input-based Security Problems • Injection Flaws • Insecure Remote File Inclusion • Unvalidated Input Authentication and Authorization • Authentication • Access Control • Cross-Site Attacks Other Bugs • Error Handling and Information Leakage • Insecure Storage • Insecure Communications IMI Security Symposium

15. SQL Injection Attacker • App sends form to user. • Attacker submits form with SQL exploit data. • Application builds string with exploit data. • Application sends SQL query to DB. • DB executes query, including exploit, sends data back to application. • Application returns data to user. ‘ or 1=1-- User Pass Firewall DB Server Web Server IMI Security Symposium

16. Cross-Site Scripting Web Server 8. Attacker hijacks user session. 1. Login Attacker User 2. Cookie 5. XSS URL 3. XSS Attack 6. Page with injected code. 7. Browser runs injected code. 4. User clicks on XSS link. Evil site saves ID. IMI Security Symposium

17. Web Application Attack Surface cookies form inputs HTTP headers URLs IMI Security Symposium

18. Traditional Web Applications HTTP Request (form submission) User waits Server processing HTTP Response (new web page) User interaction HTTP Request (form submission) Server processing User waits HTTP Response (new web page) IMI Security Symposium

19. AJAX Asynchronous Javascript and XML • User interacts with client-side Javascript. • Javascript makes asynchronous requests to server for data. • Continues to allow user to interact with application. • Updates when receives encoded data from server. IMI Security Symposium

20. AJAX Applications Client-side Code HTTP request (asynchronous) HTTP Response (data) Server processing User interaction partial update partial update HTTP request (asynchronous) User interaction Server processing HTTP Response (data) HTTP request (asynchronous) User interaction HTTP Response (data) partial update Server processing partial update IMI Security Symposium

21. Example Client-side Code var auth = checkPassword(user, pass); if (auth == false) { alert(‘Authentication failed.’); return; } var itemPrice = getPrice(itemID); debitAccount(user, itemPrice); downloadItem(itemID); IMI Security Symposium

22. client-side code client-side state cookies form inputs HTTP headers client-side data transforms URLs server API AJAX Application Attack Surface IMI Security Symposium

23. Drilling Down: Mapping the Application • Visible Content • Spider the site. • Browse site while using intercepting proxy. • Hidden Content • Unlinked sections of site. • Backup copies of live files. • Configuration and include files. • Source code. • Log files. IMI Security Symposium

24. Entry Points For each resource found, identify inputs: • Additional path parameters • Query string • POST parameters • Cookies • HTTP headers IMI Security Symposium

25. Database interaction Displays user-supplied data Error messages File upload/download Login SQL injection. Cross-site scripting. Information leakage. Path traversal. Authentication, session management, access control flaws. Application Feature Vulnerability Map IMI Security Symposium

26. Code Auditing Why? • Find vulnerabilities faster than testing. • Find different vulnerabilities than testing. What? • Identify modules of high business risk. • Use static analysis to find common vulnerabilities. • Manually review code + static analysis results. Who? • Developers, security team, outside auditors. When? • On a regular basis, at least once before release. IMI Security Symposium

27. Static Analysis Automated assistance for code auditing Speed: review code faster than humans can Accuracy: hundreds of secure coding rules Tools • Coverity • FindBugs • Fortify • Klocwork • Ounce Labs Results IMI Security Symposium

28. Fuzz Testing Fuzz testing consists of • Sending unexpected input. • Monitoring for exceptions. IMI Security Symposium

29. Monitoring for Exceptions Application mapping • Response code • Response size • Presence of string “not authorized” Password guessing • Response code • Response size • Presence of string “login incorrect” IMI Security Symposium

30. Prevention Guidelines • Use a standard, secure authentication scheme. • Check access control on every transaction. • Avoid using interpreters where possible. • Don’t leak sensitive information in error pages. • Encrypt sensitive data in transit and on disk. • Encode user data in output. • Don’t trust any data from the client. • Validate all input. IMI Security Symposium

31. Input Validation Blacklist: reject known bad input • Reject input matching list of bad strings/patterns. • Accept all other input. • Vulnerable to encoding attacks. Whitelist: accept known good input • Accept input matching list of good strings/patterns. • Reject all other input. • Highly effective, but not always feasible. IMI Security Symposium

32. Visible Content • Linked URLs. • Authenticated URLs. • Hidden Content • Unlinked sections of site. • Backup copies of live files. • Configuration/include files. • Source code. • Log files. client-side code client-side state cookies form inputs is nearly fractal. HTTP headers client-side data transforms URLs server API external web apps external web server A site’s attack surface internal web apps firewall VPN internal web servers database wireless IMI Security Symposium