Miscellaneous Security

Reading time: 3 – 4 minutes

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.

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.

Reading time: 2 – 4 minutes

Photo: malik ml williams

This is the last-part in a ten-part-series describing the OWASP Top 10. (See the entire OWASP Top 10)

What is the problem with Failing to Restrict URL Access

A common problem in web applications, failing to restrict URL access typically happens when a page doesn’t have the correct access control policy in place. Unauthorized users are able to view content that they shouldn’t have the ability to view.

Having these vulnerabilities in your application exposes privileged functionality to unauthorized users. It can also create a problem with your record trails. If users can access records without being authenticated the chain of custody is completely broken, preventing good auditing from taking place.

Failing to restrict URL access can also lead to problems with bypassing session management, another of the OWASP Top 10.

An Example of Failing to Restrict URL Access

Developers attempting to hide functionality from a user by creating “hidden” pages can create a failure to restrict URL access situation.

Hidden pages are defined as pages that don’t have a link pointing to them, preventing web crawlers, such as Google, from indexing them. Some developers believe that these pages will never be found by anyone who doesn’t know the exact URL. However, attackers typically find these pages through forceful browsing and the access controls on these pages tend to not be restrictive.

Another example of a page that can have this type of vulnerability is one where all of the privileges are checked client side but not server side. Attackers using personal proxies can bypass these client-side privileges and access functionality not intended for them to access.

How Do You Restrict URL Access

Most of these problems arise from a change in policy happening on paper, but not being implemented thoroughly across the application.

Restricting URL access correctly takes careful planning by the developer and the supporting organization. Organizations can follow some simple rules that will help them in preventing this vulnerability.

• Developers should never assume users will be unaware of hidden functionality.
• Administrators should block access to all file types that the application doesn’t serve.
• Architects should develop an access control matrix, helping them to prevent unauthorized users from accessing authorized content. This should be done for every URL and business function of the application.

Reading time: 2 – 4 minutes

Photo: Rionda

While attending OWASP AppSec DC this week, I was able to see the preliminary release of the OWASP top 10 for 2010. This is the first release candidate and the 2010 top 10 are now available for public comment. We will soon see what the security community thinks of it, but OWASP is hoping for an finalized release in the early first quarter of 2010.

For regular readers, you will not see much new on the OWASP top 10 2010. The main change is the order, or rather priority, of vulnerabilities has been changed. While the OWASP Top 10 – 2007 list focused on the top 10 vulnerabilities in web applications. The 2010 top 10 have been re-clarified to reflect the Top 10 Application security risks to an organization.

The 2007 list also focused on the frequency of the occurrences of the vulnerabilities in the web application. However, the OWASP Top Ten 2010 list is prioritized based on an estimated risk to the organization.

Risks Added to the OWASP 2010 Top 10

The new vulnerabilities are Security Misconfiguration (A6) and Unvalidated Redirects and Forwards (A8). I will address these two risks in future articles.

Vulnerabilities Removed from the OWASP 2010 Top 10

Since two risks were added, the OWASP had to replace vulnerabilities that were already on the list. These vulnerabilities are Malicious File Execution and Information Leakage and Improper Error Handling.

Malicious File Execution has been removed due to the reduction of how prevalent this vulnerability is now compared to 2007. OWASP also states that PHP is being shipped with more default security built-in. This is why it has been removed from the list.

Information Leakage and Improper Error Handling has been removed from the typical low impact of disclosing stack traces and error messages to the user. (Personally, I disagree with this.)

OWASP Top 10 2010 RC1

A1 – Injection
A2 – Cross-Site Scripting (XSS)
A3 – Broken Authentication and Session Management
A4 – Insecure Direct Object References
A5 – Cross Site Request Forgery (CSRF)
A6 – Security Misconfiguration
A7 – Failure to Restrict URL Access
A8 – Unvalidated Redirects and Forwards
A9 – Insecure Cryptographic Storage
A10 – Insecure Communications

We shall see in the next few months what the community thinks of these changes.