Assuring Your Web Application Security

1. Assuring Your Web Application Security Will Smith, CISA Senior IT Auditor E. W. Scripps IIA Cincinnati Research Chair

2. Background • CISA and 4 years in IT Audit • Worked in IT for 12 years • Network Engineer • Consulting - Systems Engineer • Consulting - Security Specialist • Multiple Industries • Non Profit and Government • Insurance • News and Media • Manufacturing

3. Objectives • Overview of Web Application Threats • 3 Levels of Web Application Hardening • Additional Resources

4. A hacker can social-engineer his way into your cloud storage and delete everything you have. It turns out, a billing address and the last four digits of a credit card number are the only two pieces of information anyone needs to get into your iCloud account. Once supplied, Apple will issue a temporary password, and that password grants access to iCloud. Apple tech support confirmed to me twice over the weekend that all you need to access someone's AppleID is the associated e-mail address, a credit card number, the billing address, and the last four digits of a credit card on file. Here's how a hacker gets that information. • First you call Amazon and tell them you are the account holder, and want to add a credit card number to the account. All you need is the name on the account, an associated e-mail address, and the billing address. Amazon then allows you to input a new credit card. (Wired used a bogus credit card number from a website that generates fake card numbers that conform with the industry's published self-check algorithm.) Then you hang up. • Next you call back, and tell Amazon that you've lost access to your account. Upon providing a name, billing address, and the new credit card number you gave the company on the prior call, Amazon will allow you to add a new e-mail address to the account. From here, you go to the Amazon website, and send a password reset to the new e-mail account. This allows you to see all the credit cards on file for the account -- not the complete numbers, just the last four digits. But, as we know, Apple only needs those last four digits. We asked Amazon to comment on its security policy, but didn't have anything to share by press time. And it's also worth noting that one wouldn't have to call Amazon to pull this off. Your pizza guy could do the same thing, for example. If you have an AppleID, every time you call Pizza Hut, you're giving the 16-year-old on the other end of the line all he needs to take over your entire digital life. http://www.wired.com/gadgetlab/2012/08/... The victim's initial post: http://www.emptyage.com/post/28679875595/... Update: Apple has changed its policy and stopped taking phone-based password reset requests, pretty much as a result of this incident, and has beefed up security: http://www.networkworld.com/news/2012/...

5. Overview of Web Application Threats • Web based attacks focus on an application itself and functions on layer 7 of the OSI. • Uses your own application against you. • Typically appears to be a valid user • Doesn’t typically try to beat the door down • Targets vulnerable portions of your application and sneaks in • Five basic categories • Spoofing, Repudiation, Information Disclosure, Denial of Service, Elevation of Privileges

6. 3 Levels of Web Application Hardening • Vulnerability Prevention • Make sure your application does what it is supposed to and not what you don’t want it to do. • Attack Vector Analysis • Analyze your applications and infrastructure for potential attacks • Attack Detection and Prevention • Be aware of real time attacks and respond quickly

7. Vulnerability Prevention • User Input Validation • API – ESAPI, STRUTS • Vetted API’s provide reasonable assurance of effectiveness. • Built In House • Additional testing should be conducted with security. • Use of Application Code Review software • Parameters for Input Validation • Only allow what is necessary for input. Filter, Filter, Filter • Integer or text • White list, don’t black list. • Define the context and length – i.e. 16 integers or valid first names • Canonization – plain ASCII – no HTML input etc.

8. Vulnerability Prevention • Filter the data • Server side filtering not Host filtering • Check all your sources: GUI, Cookies, Files • Multiple validations are Okay! • Encode your Output • Only return what is needed in the format needed. No HTML our to a Java output. No OS commands to HTML.

9. Attack Vector Analysis • Periodically scan your network for open attack vectors • Nessus, FoundScanand the like are useful • Other open source options available, but require more expertise • Scan both internal and external • Look for what ports are open and ask should they be • Look for known vulnerabilities and get feedback on why they are still there. • Analyze the traffic on the network, what is being sent in clear text?

10. Attack Detection and Prevention • IDS and IPS • Actively scanning traffic on your network is needed • Web Applications Firewalls or Reverse Web Proxies • Since your application is being used against you, actively check inputs and outputs. • Log Monitoring or Security Information and Event Monitoring (SEIM) • Lots of data and events • Automating this process is the only way to sift through it all effectively

11. Additional Resources • SANS.org • Browse the reading room • http://www.sans.org/reading_room/whitepapers/application/appsec-protecting-web-apps-big-mistakes-12-practical-tips-avoid_33038 • http://www.sans.org/reading_room/whitepapers/application/web-based-attacks_2053 • http://www.sans.org/reading_room/whitepapers/application/assessing-vendor-application-security-practical_1370 • SANS Top 25 Vulnerabilities • OWASP.org • ESAPI and the Top Ten Web Application Vulnerabilities • www.offensive-security.com

12. Questions?