Web Application Security

1. Web Application Security Presented by Jay Jaeger and Kevin Acker

2. Overview • Application vulnerabilities are serious: your data and infrastructure are at risk.   • Web applications are involved in critical business functions and access critical resources that contain customers personal information • Unfortunately, your enemies have a lot more time at their disposal than you do, and the days of "script kiddies" are gone:  these folks mean business -- they are out to make money off of your vulnerabilities.

3. Web Applications Under Siege Network DoS Attack Port Knocker Knob Twister App. DoS Attack Application Attack Malformed Web URLs Operating System Attack Network Port Attack

4. Overall Issues/Risks • There are many different issues and risks that need to be considered when looking at the bigger picture of web application security. • Legacy web application security technology issues • Don’t forget about those old versions of software still running both mission critical and non-mission critical web applications. These apps may need additional protection/segmentation from the rest of the world. • Orgs sometimes just focus on “securing” their “mission critical” apps but a vulnerability in any app could let someone “in the door”.

5. Overall Issues/Risks (cont.) • If you are not designing and coding with care, you certainly have serious vulnerabilities • Numerous kinds of vulnerabilities: SQL injection in input, overflows on field lengths, cross site scripting attacks, etc. Refer to OWASP site for additional info. • Overwhelming amount of information on web application security makes digesting the really important pieces challenging. • Code review is expensive but necessary (especially for externally facing web applications), and is cheaper than being compromised later. Automated code review tools can cut down on staff costs in this area.

6. Overall Issues/Risks (cont.) • Even if you are designing and coding with care, you probably still have vulnerabilities • New ones show up all the time • Doing this right is hard right now.  It takes skilled people focused on this to do it as well as possible. • Focus on “defensible” applications since it is nearly impossible to have an application that is free from all vulnerabilities, i.e. don’t forget due diligence. • Open source components and frameworks have bugs just like proprietary software.

7. Overall Issues/Risks (cont.) • Keep up to date with patches both at the server and application layers. This is hard to do due to the large number of "apps" that organizations have running on their servers. • Don’t rely on vendors who include other products with their software to include security patches for those products. • Without good change management you may have applications in production you weren’t even aware of. • If exposing “test” environments to the internet they need to be hardened since they are entry points to the organization’s environment as well.

8. Overall Issues/Risks (cont.) • Infrastructure is necessary but is just part of the solution • Reverse proxies and proxy based firewalls can filter and validate HTTP traffic, some down to the field/parameter level • Defense in depth: avoiding dependence on single providers, called "mono cultures", i.e. watch out for using the same vendor for all of your security layers. • Don’t just depend on your hardware firewall to protect you.

9. Infrastructure Helps – Some Network Port Attack Network DoS Attack Network Port Attack Malformed Web URLs Application Attack App. DoS Attack Operating System Attack Port Knocker Knob Twister

10. Overall Issues/Risks (cont.) • Developers should work with infrastructure support staff to learn what infrastructure security pieces are in place to help protect applications and their data. • Integration with a 3rd party account provisioning and management application can help reduce potential security exposures from attempting to roll your own in this space. • Even with “perfect” infrastructure security you still need to secure the application itself.

11. Mitigation Strategies • There are a number of areas that can be used to mitigate some of the risks and issues associated with web application security. • "Constant Vigilance!!" • Always drink from your hip flask:  Never trust anything that comes from the web browser / client (even from applets/.NET client side controls you wrote and distributed) • Use your "dark detectors":  If you are not monitoring your firewall, system and application logs (not just security logs) and following up you are more vulnerable • Use your "foe glass":  If you are not following bug reports, you are more vulnerable • Complacency and overconfidence are your enemies. Don’t ever pretend that problems don’t exist. “Constant Vigilance!!”

12. Mitigation Strategies (cont.) • Whether or not to use proxy accounts to access back-end resources • Can make auditing more difficult, but allows clean separation of security domains. • Always necessary for "public" web applications • Protecting credentials cannot be air-tight since the application still needs to get at the data. • Isolate components into appropriate security zones

13. Protecting the Crown Jewels Prod. Applications Test and/or Unrelated Applications Internet Firewall Production Database Access Firewall Use Security Zones to constrain access to appropriate places.

14. Mitigation Strategies (cont.) • Testing is critically important • Regression test after changes. • Recognize that regardless of testing, some flaws will slip thru • Automated tools can help test for security flaws • Validate server certificates when connecting to web services • Whether using back-end “proxy” accounts for applications, or direct user-provided accounts, give the accounts access to only the views of data that are required to accomplish the necessary transactions.

15. Sensitive Data All Over !!! Network Transmissions S S Browser Network Transmissions S S S S S Session Data Application Server, Application Components S S Customer Data Transaction Data

16. Mitigation Strategies (cont.) • Minimize where you store sensitive data • Encrypt sensitive data in storage (especially sensitive information stored in application configuration files) and in transit over the network. • Avoid storing credit card numbers, account numbers or other sensitive information in a database or even in an object that is persistent within the application.

17. Protect That Data !!! S S Encrypted Network Transmissions Encrypted Network Transmissions Browser H S S K K Session Data Application Server, Application Components K S H Normalized Customer Data One-Way Hash of Sensitive Data

18. Mitigation Strategies (cont.) • SOA may also provide help • Provides a natural security boundary • However, issues with exposing data via web services to other applications contains another set of security risks since your data is no longer completely under your control

19. Mitigation Strategies (cont.) • Sharing and collaboration of information within the state and across government entities. • Should we have a common site for collaborating / two way information flow about these topics within the state or across government entities? • Share the load on following bug reports, but avoid single individuals being the only ones looking at any given information source. • Collaborate on design patterns, mitigation strategies. App Best Practices group will be re-forming to help with some of this. • There is a fair amount of duplication of effort across government with respect to checking for and remediating security issues.

20. Web Application Security – Java Focus • Java has some characteristics that are helpful  • Virtual machine • Garbage Collection model avoids many memory re-use bug scenarios • Pointer restrictions -- prevents many kinds of coding errors • Object Oriented -- introduces thought discipline • "Java 2 Security Sandbox" • Allows you to recognize and disallow aberrant behavior • Though most Java shops don't use it for server side applications, they probably should.

21. Web Application Security – Java Focus (cont.) • Shared components and frameworks • Others can test more thoroughly than you can • Introduces repeatability into the development process • But still, some bugs can still remain • Open source can end up with more "good" eyes looking for security issues -- but that is not necessarily always true.

22. Web Application Security - .NET Focus • Application Pools in IIS - Run under the least privileged account possible. Avoid running applications under the System if at all possible. • NTFS Permissions on files – Always use the least permissions possible on the application and system files. • Tools: • Many utilities from Microsoft and other vendors such as IIS Trace, Debug Diagnostics, etc. allow you to look at real-time and historical activity to determine if/when security problems occurred. • Other tools such as CAT.NET and TAM-E (both still under development within Microsoft) will allow for deeper code analysis and threat modeling.

23. Web Application Security - .NET Focus (cont.) • In ASP.NET, the semi-equivalent of the "sandbox" in Java is called Code Access Security and almost no one uses it. • Common Configuration File Security Issues • Custom Errors Disabled • Leaving Tracing and Debugging Enabled • Cookie related issues • Hard-coded Credentials Used

24. Web Application Security Resources • OWASP web site is a great place for information on all types of web application security issues – http://www.owasp.org • Top 10 current vulnerabilities that people building web applications need to be aware of - http://www.owasp.org/index.php/Top_10_2007 • The Web Application Security Consortium (WASC) is an international group of experts, industry practitioners, and organizational representatives who produce open source and widely agreed upon best-practice security standards for the World Wide Web – http://www.webappsec.org/