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?