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 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 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 address to the account. From here, you go to the Amazon website, and send a password reset to the new 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.
The victim's initial post:
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:

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, FoundScan and 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 OWASP.org www.offensive-security.com
Browse the reading room
web-apps-big-mistakes-12-practical-tips-avoid_33038
attacks_2053
application-security-practical_1370
SANS Top 25 Vulnerabilities
OWASP.org
ESAPI and the Top Ten Web Application Vulnerabilities

12. Questions?