Cross-Site Scripting in 37Signals Writeboard Application

Posted by Brett Hardin on 3rd February 2010

Reading time: 3 – 4 minutes

Cross Site Scripting in 37Signals Writeboard Application

Photo: jurvetson

While recently using Basecamp, a 37Signals product, I was writing a collaborative document using Writeboard and noticed that I could insert greater than (<) and less than ( > ) tags in the document.

Writeboard uses a simpler form of editing, similar to wiki’s. If you want to make the line bold, you can use *bold* instead of standard HTML, <b>bold</b>. However, Writeboard allows the user to markup the text either way. Well, this was a product that I needed to QA. I quickly inserted a script source tag, saved the Writeboard, and to my surprise, the script src tag fired.

Upon identifying this I then attempted Cross-Site Scripting 101: <script> alert (123) </script>

That also was successful! I was rather blown away that a product who is used by, Adidas, National Geographic, Kellogg, and USA Today, has never tested (or accidental) found this functionality.

I reached out to the security team at 37Signals, and the issue has been fixed and I have been given a nice shout out on the security page.

I initially thought, “This is what happens when start-ups attempt to rush products to market without doing sanity checking on what they are doing.”

However, upon further research, I read the excellent “book” Get Real by Jason Fried the Founder of 37Signals.  These essays explained why this type of vulnerability lived in this system. 37Signals follows a process of quick deployment, development, with fast subsequent revisions. Their concept is get a product out that people can immediately begin using.

XSS in 37Signals WriteBoard product

Cross-Site Scripting in 37Signals

While I agree, this is a great way to develop SaaS products, it is difficult to see how security can come into play with this type of software delivery model. In one essay, Fried, explains the necessity of getting well rounded individuals (generalists) and avoid hiring specialists. Does this mean more software developers should be interested in security?

This is yet to be seen, and I think it is dependent upon your product. There is something however that other companies can learn from 37Signals.

37 Signals did the following when it came to me finding this bug:

  • I initially reached out to Jason Fried on Twitter, and he got back to me in less than an hour.
  • They had a simple way for me to contact them.
  • After reaching out to them, they immediately acknowledged the receiving of my message.
  • They fixed the issue in 4 days.

I commend 37Signals for fixing the issue as fast as they did. Typically, when these issues are reported to companies, they are typically forwarded to the trash.

3Feb

OWASP Top 10 Presentation

Posted by Brett Hardin on 21st October 2009

Reading time: 1 – 2 minutes

I recently did a presentation on the OWASP Top 10 for SecurityStreams. Nitesh Dhanjani of SecurityStreams was nice enough to allow me to embed the videos of the presentations on this site.

If you are new to the OWASP Top 10, I highly suggest to watch this presentation, it is about 45 minutes and should give you a high level understanding of all the OWASP Top 10.

If you are an executive or don’t have time to watch the full presentation, then I suggest watching the 10 minute executive presentation.

Make sure to watch them in HD (Upper right hand corner of the videos). Let me know your thoughts and comments.

OWASP Top 10 – Full Presentation

OWASP Top 10 – Executive Presentation

21Oct

OWASP Top 10 2007

Posted by Brett Hardin on 6th July 2009

Reading time: 2 – 2 minutes

OWASP Top 10 2007
When developing a security strategy for web applications many companies have no idea where to begin. The Open Web Application Security Project (OWASP) understood this problem and developed the OWASP Top 10.

The OWASP top 10 are the top 10 vulnerabilities that are found in web applications. If you have an hour or don’t want to read all of these posts, you can simply watch a video.

If you are a developer, you should understand these vulnerabilities. Understanding them is critical into introducing less vulnerabilities into your code.

The OWASP Top 10:
A1 – Cross Site Scripting (XSS)
A2 – Injection Flaws
A3 – Malicious File Execution
A4 – Insecure Direct Object Reference
A5 – Cross Site Request Forgery (CSRF)
A6 – Information Leakage and Improper Error Handling
A7 – Broken Authentication and Session Management
A8 – Insecure Cryptographic Storage
A9 – Insecure Communications
A10 – Failure to Restrict URL Access

6Jul