Web Application Security
Overview
Background
Web app vulnerabilities
Securing web apps
Background
HTTP
Hypertext Transfer Protocol
• “Hypertext Transfer Protocol (HTTP) is a
communications protocol for the transfer of
information on intranets and the World Wide Server
Web. Its original purpose was to provide a www.mybank.com
way to publish and retrieve hypertext pages
over the Internet.” (64.58.76.230)
• http://en.wikipedia.org/wiki/HTTP Port: 80
Client PC
(10.1.0.123)
Request
Response
HTTP Request - GET
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
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/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
http://www.google.com/search?hl=en&lr=&c2coff=1&rls=GGLG%2CGGLG%3A2005-
26%2CGGLG%3Aen&q=http%3A%2F%2Fwww.google.com%2Fsearch%3Fhl%3Den%26lr%3D%26c2coff
%3D1%26rls%3DGGLG%252CGGLG%253A2005-
26%252CGGLG%253Aen%26q%3Dhttp%253A%252F%252Fwww.google.com%252Fsearch%253Fhl%2
53Den%2526lr%253D%2526c2coff%253D1%2526rls%253DGGLG%25252CGGLG%25253A2005-
26%25252CGGLG%25253Aen%2526q%253Dhttp%25253A%25252F%25252Fwww.google.com%25252F
search%25253Fsourceid%25253Dnavclient%252526ie%25253DUTF-
8%252526rls%25253DGGLG%25252CGGLG%25253A2005-
26%25252CGGLG%25253Aen%252526q%25253Dhttp%2525253A%2525252F%2525252Fwww%25252
52Egoogle%2525252Ecom%2525252Fsearch%2525253Fsourceid%2525253Dnavclient%25252526ie%25
25253DUTF%2525252D8%25252526rls%2525253DGGLG%2525252CGGLG%2525253A2005%2525252
D26%2525252CGGLG%2525253Aen%25252526q%2525253Dhttp%252525253A%252525252F%252525
252Fuk2%252525252Emultimap%252525252Ecom%252525252Fmap%252525252Fbrowse%252525252
Ecgi%252525253Fclient%252525253Dpublic%2525252526GridE%252525253D%252525252D0%252525
252E12640%2525252526GridN%252525253D51%252525252E50860%2525252526lon%252525253D%2
52525252D0%252525252E12640%2525252526lat%252525253D51%252525252E50860%2525252526se
arch%252525255Fresult%252525253DLondon%25252525252CGreater%252525252520London%252525
2526db%252525253Dfreegaz%2525252526cidr%252525255Fclient%252525253Dnone%2525252526lan
g%252525253D%2525252526place%252525253DLondon%252525252CGreater%252525252BLondon%2
525252526pc%252525253D%2525252526advanced%252525253D%2525252526client%252525253Dpub
lic%2525252526addr2%252525253D%2525252526quicksearch%252525253DLondon%2525252526addr3
%252525253D%2525252526scale%252525253D100000%2525252526addr1%252525253D%2526btnG%
253DSearch%26btnG%3DSearch&btnG=Search
HTTP Requests - POST
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
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/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
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
Very complex architectures, Web Application
multiple platforms, multiple
HTTP
Web Services protocols
Network
Application Database
Web Servers Server Server
Wireless
Presentation Business Customer
Layer Logic Identification
Media Store Content Access
Services Controls
Browser
Transaction
Information
Core Business
Data
Web Applications Breach the
Perimeter
Trusted
Internet DMZ
Inside
IIS ASP
SunOne .NET
SQL
WebSphere
Apache Oracle
Java
DB2
HTTP(S) Corporate
Browser Firewall only Inside
allows Firewall only
Allows HTTP port 80 allows application
applications
on the web server to talk to
Allows HTTPS port 443 database server.
server to talk to
application
server.
Why Web Application
Vulnerabilities Occur
The Web Application
Security Security Gap Application
Professionals Developers and
Don’t Know The QA Professionals
Applications Don’t Know
Security
“As a Network Security “As an Application
Professional, I don’t Developer, I can
know how my build great features
companies web and functions while
applications are meeting deadlines,
supposed to work so I but I don’t know
deploy a protective how to develop my
solution…but don’t web application
know if it’s protecting with security as a
what it’s supposed to.” 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
Technical Vulnerabilities
• Result of insecure programming techniques
• Mitigation requires code changes
• Detectable by scanners
• http://example/order.asp?item=<script>alert(‘p0wned’)</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
Application Mapping
Administration Cookie Manipulation
Extension Checking Custom Application
Scripting
Common File Checks
Parameter Manipulation
Platform Data Extension Checking
Reverse Directory
Backup Checking Transversal
Known Vulnerabilities
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:
• Known vulnerabilities can be
exploited immediately with a
minimum amount of skill or
experience – “script kiddies”
Platform
Known
• Most easily defendable of all
Vulnerabilities web vulnerabilities
• MUST have streamlined
patching procedures
Web Application Vulnerabilities
Administration:
Administration
• Less easily corrected than known
issues
Extension Checking
Common File Checks • Require increased awareness
Data Extension
Checking
• More than just configuration, must
be aware of security flaws in actual
Backup Checking
Directory
content
Enumeration • Remnant files can reveal
Path Truncation
applications and versions in use
Hidden Web Paths
Forceful Browsing
• Backup files can reveal source code
and database connection strings
Web Application Vulnerabilities
Application Programming:
•
Common coding techniques do not
necessarily include security
Application
• Input is assumed to be valid, but not tested
Administration
Application Mapping
• Unexamined input from a browser can inject
Cookie Manipulation scripts into page for replay against later
Custom Application visitors
Scripting
Parameter Manipulation
• Unhandled error messages reveal application
and database structures
Reverse Directory
Transversal • Unchecked database calls can be
Brute Force ‘piggybacked’ with a hacker’s own database
Application Mapping call, giving direct access to business data
Cookie Poisoning/Theft
through a web browser
Buffer Overflow
SQL Injection
Cross-site scripting
How to Secure Web Applications
Incorporate security into the lifecycle
• Apply information security principles to all
software development efforts
Educate
• Issue awareness, Training, etc…
How to Secure Web Applications
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?
