Web Application Security 101 Steve Carter special thanks

Web Application Security 101 Steve Carter (special thanks to SPI Dynamics)

Overview l l l Background Web app vulnerabilities Securing web apps

Background

HTTP l • • Hypertext Transfer Protocol “Hypertext Transfer Protocol (HTTP) is a communications protocol for the transfer of information on intranets and the World Wide Web. Its original purpose was to provide a way to publish and retrieve hypertext pages over the Internet. ” http: //en. wikipedia. org/wiki/HTTP Client PC (10. 123) Request Response Server www. mybank. com (64. 58. 76. 230) Port: 80

HTTP Request - GET l l l Form data encoded in the URL Most common HTTP method used on the web Should be used to retrieve information, not for actions that have side-effects

HTTP Request - GET http: //www. mysite. com/kgsearch/search. php? catid=1 HTTP/1. 1 Host: www. mysite. com User-Agent: Mozilla/5. 0 (Windows; U; Windows NT 5. 1; en-US; rv: 1. 8. 1. 13) Gecko/20080311 Firefox/2. 0. 0. 13 Accept: text/xml, application/xhtml+xml, text/html; q=0. 9, text/plain; q=0. 8, image/png, */*; q=0. 5 Accept-Language: en-us, en; q=0. 5 Accept-Encoding: gzip, deflate Accept-Charset: ISO-8859 -1, utf-8; q=0. 7, *; q=0. 7 Keep-Alive: 300 Connection: keep-alive Referer: http: //www. mysite. com/

HTTP Request - GET l http: //www. google. com/search? hl=en&lr=&c 2 coff=1&rls=GGLG%2 CGGLG%3 A 200526%2 CGGLG%3 Aen&q=http%3 A%2 F%2 Fwww. google. com%2 Fsearch%3 Fhl%3 Den%26 lr%3 D%26 c 2 cof f%3 D 1%26 rls%3 DGGLG%252 CGGLG%253 A 200526%252 CGGLG%253 Aen%26 q%3 Dhttp%253 A%252 Fwww. google. com%252 Fsearch%253 Fhl%2 53 Den%2526 lr%253 D%2526 c 2 coff%253 D 1%2526 rls%253 DGGLG%25252 CGGLG%25253 A 200526%25252 CGGLG%25253 Aen%2526 q%253 Dhttp%25253 A%25252 Fwww. google. com%25252 F search%25253 Fsourceid%25253 Dnavclient%252526 ie%25253 DUTF 8%252526 rls%25253 DGGLG%25252 CGGLG%25253 A 200526%25252 CGGLG%25253 Aen%252526 q%25253 Dhttp%2525253 A%2525252 Fwww%252525 2 Egoogle%2525252 Ecom%2525252 Fsearch%2525253 Fsourceid%2525253 Dnavclient%25252526 ie%252 5253 DUTF%2525252 D 8%25252526 rls%2525253 DGGLG%2525252 CGGLG%2525253 A 2005%2525252 D 26%2525252 CGGLG%2525253 Aen%25252526 q%2525253 Dhttp%25253 A%25252 F%2525252 52 Fuk 2%25252 Emultimap%25252 Ecom%25252 Fmap%25252 Fbrowse%25252 E cgi%25253 Fclient%25253 Dpublic%252526 Grid. E%25253 D%25252 D 0%2525252 52 E 12640%252526 Grid. N%25253 D 51%25252 E 50860%252526 lon%25253 D%25 2525252 D 0%25252 E 12640%252526 lat%25253 D 51%25252 E 50860%252526 sea rch%25255 Fresult%25253 DLondon%2525252 CGreater%25252520 London%2525252 526 db%25253 Dfreegaz%252526 cidr%25255 Fclient%25253 Dnone%252526 lang %25253 D%252526 place%25253 DLondon%25252 CGreater%25252 BLondon%25 25252526 pc%25253 D%252526 advanced%25253 D%252526 client%25253 Dpubli c%252526 addr 2%25253 D%252526 quicksearch%25253 DLondon%252526 addr 3 %25253 D%252526 scale%25253 D 100000%252526 addr 1%25253 D%2526 btn. G% 253 DSearch%26 btn. G%3 DSearch&btn. G=Search

HTTP Requests - POST l l Data is included in the body of the request. Should be used for any action that has side-effects • Storing/updating data, ordering a product, etc…

HTTP Requests - POST http: //www. mysite. com/kgsearch/search. php HTTP/1. 1 Host: www. mysite. com User-Agent: Mozilla/5. 0 (Windows; U; Windows NT 5. 1; en-US; rv: 1. 8. 1. 13) Gecko/20080311 Firefox/2. 0. 0. 13 Accept: text/xml, application/xhtml+xml, text/html; q=0. 9, text/plain; q=0. 8, image/png, */*; q=0. 5 Accept-Language: en-us, en; q=0. 5 Accept-Encoding: gzip, deflate Accept-Charset: ISO-8859 -1, utf-8; q=0. 7, *; q=0. 7 Keep-Alive: 300 Connection: keep-alive Referer: http: //www. mysite. com/ catid=1

Famous quote of the day “Every program has at least two purposes: the one for which it was written, and another for which it wasn't. ” -Alan J. Perlis

GET v. POST Security l l l There information contained in parameters can tell a user a lot about how your application works GET parameters are easily visible in the address bar POST parameters are hidden from the average user • • • Users can still view source code Users can still view the packets Users can still intercept & modify web requests

Web Sites ØNo applications ØStatic pages ØHard coded links Browser Web Server

Web Applications Web Services Very complex architectures, multiple platforms, multiple protocols Web Application HTTP Network Web Servers Database Server Presentation Layer Wireless Application Server Business Logic Customer Identification Media Store Browser Content Services Access Controls Transaction Information Core Business Data

Web Applications Breach the Perimeter Internet IIS Sun. One Apache Trusted Inside DMZ ASP. NET Web. Sphere Java SQL Oracle DB 2 HTTP(S) Browser Allows HTTP port 80 Allows HTTPS port 443 Firewall only allows applications on the web server to talk to application server. Firewall only allows application server to talk to database server. Corporate Inside

Why Web Application Vulnerabilities Occur Security Professionals Don’t Know The Applications “As a Network Security Professional, I don’t know how my companies web applications are supposed to work so I deploy a protective solution…but don’t know if it’s protecting what it’s supposed to. ” The Web Application Security Gap Application Developers and QA Professionals Don’t Know Security “As an Application Developer, I can build great features and functions while meeting deadlines, but I don’t know how to develop my web application with security as a feature. ”

Web Application Vulnerabilities “If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. ” -Weinberg's Second Law

Web Application Vulnerabilities l l Technical Vulnerabilities • • Result of insecure programming techniques Mitigation requires code changes Detectable by scanners http: //example/order. asp? item=<script>alert(‘p 0 wned’)</scri pt>&price=300. 00 Logical Vulnerabilities • • • Result of insecure program logic Most often to due to poor decisions regarding trust Mitigation often requires design/architecture changes Detection often requires humans to understand the context http: //example/order. asp? item=toaster&price=30. 00

Web Application Vulnerabilities Web application vulnerabilities occur in multiple areas. Application Administration Extension Checking Common File Checks Platform Known Vulnerabilities Data Extension Checking Application Mapping Cookie Manipulation Custom Application Scripting Parameter Manipulation Backup Checking Reverse Directory Transversal Directory Enumeration Brute Force Path Truncation Application Mapping Hidden Web Paths Cookie Poisoning/Theft Forceful Browsing Buffer Overflow SQL Injection Cross-site scripting

Web Application Vulnerabilities Platform: • Platform Known Vulnerabilities • • Known vulnerabilities can be exploited immediately with a minimum amount of skill or experience – “script kiddies” Most easily defendable of all web vulnerabilities MUST have streamlined patching procedures

Web Application Vulnerabilities Administration: Administration Extension Checking Common File Checks Data Extension Checking • • • Backup Checking Directory Enumeration Path Truncation Hidden Web Paths Forceful Browsing • • Less easily corrected than known issues Require increased awareness More than just configuration, must be aware of security flaws in actual content Remnant files can reveal applications and versions in use Backup files can reveal source code and database connection strings

Web Application Vulnerabilities Application Programming: • Application Mapping Cookie Manipulation Custom Application Scripting Parameter Manipulation Reverse Directory Transversal Brute Force Application Mapping Cookie Poisoning/Theft Buffer Overflow SQL Injection Cross-site scripting Common coding techniques do not necessarily include security • Input is Administration assumed to be valid, but not tested • Unexamined input from a browser can inject scripts into page for replay against later visitors • Unhandled error messages reveal application and database structures • Unchecked database calls can be ‘piggybacked’ with a hacker’s own database call, giving direct access to business data through a web browser

How to Secure Web Applications l Incorporate security into the lifecycle • Apply information security principles to all software development efforts l Educate • Issue awareness, Training, etc…

How to Secure Web Applications l Incorporating security into lifecycle • • • Integrate security into application requirements Including information security professionals in software architecture/design review Security APIs & libraries (e. g. ESAPI, Validator, etc. ) when possible Threat modeling Web application vulnerability assessment tools

How to Secure Web Applications Educate • Developers – Software security best practices • Testers – Methods for identifying vulnerabilities • Security Professionals – Software • development, Software coding best practices Executives, System Owners, etc. – Understanding the risk and why they should be concerned

Questions?