Web Application Security
ECT 582
Robin Burke
Outline
SSL Web appliation flaws
configurationapplication designimplementationstate managementcommand injectioncross-site scripting
Secure Sockets Layer
Socket: The Berkeley Unix mechanism for creating a virtual connection between processes. Sockets interface Unix's standard I/O with its network communication facilities....The socket has associated with it a socket address, consisting of a port number and the local host's network address.
-- FOLDOC
Network Layers
Session Layer
Not normally part of the "big four" part of the original OSI 7-layer picture
A session layer establishes a connection between client and server extends beyond individual TCP/IP
connections not part of any particular application
Precisely where web encryption should reside no need to change application can be used over an extended interaction
SSL (now TLS)
Establishes how a client and server can exchange encrypted content
GoalsCryptographic securityInteroperabilityExtensibilityRelative efficiency
Protocol phases
ClientHello request to use SSL/TLS
• https in browser includes client-generated random number
ServerHello confirmation that SSL/TLS is available includes server-generated random number usually followed by server certificate
ClientKeyExchange client computes a secret key and encrypts it
• or client initiates Diffie-Helman key exchange then both client and server compute a "master secret"
Protocol phases, cont'd
Master secret is key material for different purposes client MAC secret, server MAC secret, client encryption key, server encryption key, client write IV server write IV,
Finished server and client exchange encrypted message contains a hash of all of the messages exchanged in
the protocol so far final verification of "agreed to" parameters
Protocol phases, cont'd
Client can request resumption of previously-negotiated interaction server policies on time-out control
Options Server can request a client certificate
• two-way authentication Either client or server can request that the
cipher parameters be changed• can happen at any time• renegotiation
Overhead
Communication overhead both sides exchange much more data
• certificates, etc.
Computational overhead certificate verification cryptographic operations
In general protect only those communications where
content must be protected
PKI
SSL/TLS assumes PKICertificate authenticates server
In realityverification path limited to browser
defaults
Web Application Security
"Web application code is part of your security perimeter"
Web application securityCannot be ignoredA regular site of attacks
Example #1: Updates
75% of all web servers running MS IIS 5.0 are vulnerable to exploitation.
Microsoft issued a security alert on March 17 2003 regarding a buffer overflow vulnerability which allows attackers to execute arbitrary code on Windows 2000 machines. Netcraft survey found 767,721 IPs running IIS 5.0 and
offering WebDAV and 273,496 IPs running IIS 5.0 with the protocol turned off.
-- Securitystats.com, http://www.securitystats.com/webdeface.asp:
Example #2: CGI attacks
"CGI attacks are powerful, and the vulnerabilities are common. Sure it is possible to write secure CI scripts, but hardly anyone does. One company that auits Web sites for appliation-level bugs like this has never founc a Web site they could not hack. That's 100 percent vulnerabilities."
-- Schneier, "Secrets and Lies"
Example #3: Session hijacking"In a survey of 45 Web applications in
production at client companies, @stake researchers found that 31% of e-commerce applications examined were vulnerable to session replay or hijacking -- the highest incidence of Web application security defects encountered in the study. @stake's Andrew Jaquith (2002) comments, "user session security remains the Achilles heel of most e-business applications."
-- Jeni Li "State Management in Web Applications"
The problem
Design little consideration of security in web's origins
Diversity of platforms OS (Linux, UNIX, WIndows, Mac OS, ...) Servers (IIS, Apache, ...), Browsers (Netscape, Mozilla, Internet Explorer,
Safari, Lynx, Opera, WebTV, ...) and custom scripts, Diversity of technologies
Application frameworks (Perl, PHP, Python, Java, Javascript, C, tcl, ...),
Standards (HTTP, HTML, XML, SSL, SQL, RSS, encryption, cookies, webcasts, ...),
Web development process
Web developers are (often) not programmers
Web developers (often) have no secure programming experience
Web developers (often) are adapting cookie-cutter scripts from books or on-line libraries
Web development timeframes exclude security review
Technology
Browser compensation browser will correct "errors" on the page
• interpreting a ">" as a "<"• interpreting a 'Content-Type Content="text/plain"'
metatag as if it were a "text/html".
Embedded browsers and servers difficult or impossible to patch an embedded
web server. • the "code red" virus vulnerability disabled many
printers and routers, not just web servers.
Configuration
(OWASP 10) Web-accessible directories are public hunting grounds
separate executable code E from ordinary HTML W configure server to execute (E) and display (W)
Good practice distinct directory tree for executable code
Bad practice using file extensions to distinguish between regular files and
executable ones• .pl for Perl executables• .pl.bak, .pl~ may still be viewable
putting command interpreters in executable directories• horrors!
Configuration, cont'd
Web-accessible directories are public hunting grounds Store sensitive information (passwords,
session data) outside the web-accessible directory structure
Bad practice sometimes session id files show up in
Google searches! scripts often hard-code username and
password information for databases
Configuration cont'd
The web server process is the most likely point of compromise
Create a separate user for the web server process compromise of server gives control of that account,
but not whole machine minimize the privileges of the "web server" user
Good practice have server configuration files readable but not
writable by the "web server" user Bad practice
run the server as root (administrator)
Configuration, cont'd
Some web server capabilities are inherently dangerous
Eliminate capabilities that are not strictly neededdirectory listingssymbolic linksexecutable server-side includes
Configuration, cont'd
Users can create backdoors by enabling Internet services
Good practice user education achieving a balance between limiting risk
and allowing individual initiative Bad practice
creating such draconian policies that users feel compelled to circumvent them to get things done
Application design
Input to a web application can use either "GET" or "POST" GET
faster, but information is displayed as part of URL in browser
POST information is part of request data, but not shown
Information in GET requests can leak prying eyes browser history "refer" header
Caching software may handle GET requests differently Good practice
Use POST for web applications
Application design, cont'd
(OWASP A1) Input from the browser cannot be trusted
data passed to the browser may be altered your page may not be generating the request
Good practice write a specification for valid input
• name field: [A-Za-z0-9] or . or – or ' check against it
Bad practice assuming that your Javascript validation code
protects you
Example: Hidden variables
This web page contains a form with a hidden valueThe application is passing the price as
a hidden variable in the form. An attacker could easily save the
form, edit it, and use the edited version
• ordering 100 widgets at 1 cent each
Hidden variables, cont'd
Even easier the attackercan enter the parameters into the URLif the application doesn't test for GET
vs POST http://josquin.cti.depaul.edu/cgi-bin/buyit.pl?price=0.1&order=10
Not as silly as it soundsThis weakness was actually identified
in 11 shopping applications surveyed in 2000.
Implementation
Many choices Perl, Python, PHP, Java servlets, tcl, C, a command shell,
ASP, JSP Some more secure than others
Good Perl with "taint" mode JSP ASP Python
Riskier C PHP
Dangerous command shell
State management
Web protocols is stateless one connection like any other
E-commerce applications need state user logins shopping carts
State maintenance hidden values
• problematic
cookies
Cookies
Files stored with the browser URL
identifying the originating site Cookie data
some data string Expiration date
if no date, the cookie is not permanently stored
session cookie
3rd party cookies
Scenario Site A adds a cookie to your browser
• URL: Site D• Cookie: visited site A
Site B• URL: Site D• Cookie: visited site B
etc. Site D can build a cross-site profile of browsing
behavior Browsers now report if a cookie's URL differs from its
origin there are sometimes legitimate reasons for this
State management
(OWASP A3) Cookie data can be forged
and in some cases, stolen Do not store any user data in the cookie
itself store only a session id associate id with data on the server
Good practice use a timeout to prevent hijacking provide a logout option
State management, cont'd
Browser history may leave vulnerabilities even with logout, replay may still succeed attacker goes "back" to login page and
resubmits Good practice
issue hidden random id with each login page don't allow 2nd login with same id use "no cache" headers
• but don't rely on browser compliance
Command injection
(OWASP A6) Web applications may access other
applications resident on the server data is passed from a user's request to
another application parameters can be designed to include
commands that would otherwise not be permitted
Good practice validate for legal data only
Example: shell escape
Perl program$address = $query->('address');open( MAIL, "| /usr/lib/sendmail $address" );print MAIL "Your application has been
received; thank you.\n"; close MAIL;
What this does the program /usr/lib/sendmail is run with $address as a parameter receiving input from the file handle MAIL
Shell escape, cont'd
If the address parameter is valid address = '[email protected]' then the command is
• /usr/lib/sendmail [email protected] But what if
address = 'nobody@localhost; /bin/rm -r /' the command becomes
• /usr/lib/sendmail nobody@localhost; /bin/rm –r / this will attempt to delete the server's
filesystem
Shell escape, cont'd
SolutionValidate the address parameter for
legal email address characters• letters, numbers, _, ., a single @• otherwise reject it
Also, don't shell escape• call programs directly
SQL injection
(OWASP A6) Similar to the shell scripting problem
with database access User input
used to build a database queryeasy for attacker to design input that
changes query semantics
Example: SQL injection
Cross-site scripting (XSS)
(OWASP A4) The idea
generate malicious scripting code Get user to execute
post in an open forum• guest book
embed in an innocent looking link
Example
Application codesqlCmd = "insert into names (name) value (' "
+ userName + " ');";execute (sqlCmd);
If the userName = "Burke", the SQL command isinsert into names (name) value ('Burke');
But what if the value is maliciously designeduserName = "Foo'); delete * from names where (name like '*"
Now the following commands are executedinsert into names (name) value ('Foo'); delete * from names where (name like '*');
XSS, cont'd
Encode dangerous content < < > & gt, etc
However requires a complete list of dangerous characters
• over a dozen, depending on context assumes a particular character encoding
Good practice validate against expected good input may cause some non-malicious input to be rejected
Assignment #6
web application analysis
