AtlasCamp 2010: Securing your Plugin - Penny Wyatt

2,029 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,029
On SlideShare
0
From Embeds
0
Number of Embeds
209
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

AtlasCamp 2010: Securing your Plugin - Penny Wyatt

  1. 1. SECURING YOUR PLUGIN Penny Wyatt Atlassian QA
  2. 2. Topics  Cross-Site Scripting (XSS) Vulnerabilities  Cross-Site Request Forgery (XSRF) Vulnerabilities  Confluence WebSudo  File Execution Vulnerabilities  Random Number Vulnerabilities
  3. 3. Cross Site Scripting (XSS) Vulnerabilities
  4. 4. XSS Vulnerabilities  Attacker runs JavaScript in the victim’s web browser.  Attacker can do anything the victim can.  Two types:  Persisted XSS  Reflected XSS
  5. 5. Persisted XSS Vulnerabilities  Attacker enters malicious data which is stored on the server.  The data are presented on a page, unescaped.  Requires the attacker to have permission to insert data.  Doesn’t require any action on the victim’s part.
  6. 6. Reflected XSS Vulnerabilities  Attack is inserted into a URL.  Value from the querystring is reflected directly onto the page, not stored.  Attacker gets the victim to visit the URL.  Does not require the attacker to have any access at all.  Requires some minor social engineering.
  7. 7. Fixing XSS Vulnerabilities  Where the value is inserted into plain HTML, use HTML encoding.  JIRA - $textutils.htmlEncode($name)  Confluence - $generalUtil.htmlEncode($name)  Bamboo - ${name?html}
  8. 8. Fixing XSS Vulnerabilities  Where the value is inserted into JavaScript, HTML escaping is insufficient...
  9. 9. Fixing XSS Vulnerabilities  JavaScript escaping is also dangerous.  Better approach – insert escaped value into HTML and access via the DOM.
  10. 10. Fixing XSS Vulnerabilities  Never insert user-supplied content directly into JavaScript.  Also includes other script execution methods  When feasible, restrict data server-side
  11. 11. Fixing XSS Vulnerabilities  Only escape at the Velocity level, never internally.  Strict boundary for safe/unsafe content.  Reduce risk of double-escaping.
  12. 12. Confluence Anti-XSS  Opt-in auto-escaping for Velocity templates in Confluence.  Since Confluence 2.9.  Only partial protection.  Some areas still at risk:  HTML generated by excluded methods.  HTML generated client-side.  User-supplied variables inserted into JavaScript.
  13. 13. Finding XSS Vulnerabilities  Manual code analysis  Read velocity templates, webwork, Confluence macros, any other source of HTML.  Trace the source of all parameters.
  14. 14. Finding XSS Vulnerabilities  Manual UI testing  Enter unsafe data in all form fields, including hidden fields.  Enter unsafe data into all URL parameters.  Watch for unexpected behaviour.
  15. 15. Finding XSS Vulnerabilities  Automated Scanning tools  Burp Suite, Skipfish  Useful to catch obvious flaws.  Lots of false positives, missed vulnerabilities.
  16. 16. Cross Site Request Forgery (XSRF) Vulnerabilities
  17. 17. XSRF Vulnerabilities  Attacker tricks victim into executing an action.  Action can be performed merely by visiting an URL.  Request is hidden on an unrelated page or used in conjunction with an XSS vulnerabilities.  Victim may be unaware of the action.
  18. 18. XSRF Vulnerabilities
  19. 19. XSRF Vulnerabilities
  20. 20. XSRF Vulnerabilities  Can vote for a JIRA issue by visiting a URL. https://extranet.atlassian.com/jira/secure/ VoteOrWatchIssue.jspa?id=19128&vote=vote  No XSRF protection in those days.  Embedded image on another page <img src= “https://extranet.atlassian.com/jira/secure/ VoteOrWatchIssue.jspa?id=19128&vote=vote”>
  21. 21. XSRF Vulnerabilities
  22. 22. Fixing XSRF Vulnerabilities  Limited-duration token issued by server.  Must provide that token when performing protected actions.  User can manually confirm an action if token has expired.  Since Confluence 3.0, JIRA 4.1.
  23. 23. Fixing XSRF Vulnerabilities  Step 1 (JIRA): Add @RequiresXsrfCheck to doExecute().
  24. 24. Fixing XSRF Vulnerabilities  Step 1 (Confluence): Add @RequireSecurityToken(true) to doExecute().
  25. 25. Fixing XSRF Vulnerabilities  Step 2: Add token to forms and querystrings. JIRA: Confluence:
  26. 26. Finding XSRF Vulnerabilities  Every action that changes the state of the plugin or host application is vulnerable.  Overuse of XSRF protection frustrates users.  XSRF protection easily circumvented by XSS.
  27. 27. Confluence WebSudo
  28. 28. Confluence WebSudo  Aka “Secure Administrator Sessions”  Second line of defence against XSS and XSRF attacks in Confluence.  Protects administration functions by requiring a second login into an administrative mode.  Default 10 minute rolling timeout.  Since Confluence 3.3.
  29. 29. Confluence WebSudo  @WebSudoRequired annotation  Can be disabled by sysadmins  Narrows the window in which a stolen cookie can be used to perform admin functions, but does not eliminate it.  Disabled in dev mode.
  30. 30. File Execution Vulnerabilities
  31. 31. File Execution Vulnerabilities  Allowing a user or administrator to access an arbitrary location on the file system is dangerous.  Simplest exploit – get Tomcat to serve an uploaded file.  Escalation of privileges.
  32. 32. Fixing File Execution Vulnerabilities  Never allow administrators or users to specify server file paths through the UI.  Use known safe directories.  If configuration is absolutely necessary, store the path in a .properties file on the server.
  33. 33. Random Number Vulnerabilities
  34. 34. Random Number Vulnerabilities  Random numbers are often used for security, e.g.  XSRF tokens.  Reset password tokens.  If you can predict them, you can break them.  java.util.Random is not secure.  Given one value, you can predict the next.
  35. 35. Random Number Vulnerabilities
  36. 36. Random Number Vulnerabilities  java.security.SecureRandom is better  Still can be misused.  Predictable seeding (e.g. with the system time) generates predictable values.
  37. 37. Random Number Vulnerabilities
  38. 38. Fixing Random Number Vulnerabilities  atlassian-secure-random package.  Facade for SecureRandom that correctly instantiates and seeds it.  Allows for future performance and cryptographic improvements with no future code change required.
  39. 39. Fixing Random Number Vulnerabilities  Step 1: Add dependency to the pom:  Step 2: Get the instance, then use in the same way as a SecureRandom:
  40. 40. Best Coding Practices  HTML-encode user values in Velocity.  Don’t insert user values into JavaScript.  XSRF-protect functions.  Use WebSudo for admin functions in Confluence.  Restrict file system access to known safe directories.  Use atlassian-secure-random
  41. 41. Q&A

×