Transcript Web Application Security

Web Application Security
Presented by
Jay Jaeger and Kevin Acker
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.
Web Applications Under Siege
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”.
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.
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.
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.
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.
Infrastructure Helps – Some
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.
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!!”
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
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.
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.
Sensitive Data All Over !!!
Network
Transmissions
S
S
Network
Transmissions
S
S
Browser
S
S
S
Session Data
S
Transaction Data
Application Server,
Application
Components
S
Customer Data
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.
Protect That Data !!!
S
Encrypted Network
Transmissions
Encrypted Network
Transmissions
S
S
Browser
H S
K
K
Session Data
H
One-Way Hash
of Sensitive Data
Application Server,
Application
Components
K
S
Normalized
Customer Data
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
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.
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.
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.
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.
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
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 bestpractice security standards for the World Wide Web –
http://www.webappsec.org/