OWASP Top 10 Deeper Dive - A8: Failure to Restrict URL Access

June 9, 2011 by

Russ McRee

[highlight color="blue"]Interested in formal OWASP Top 10 Training? Check out our  OWASP Top 10 Training course OWASP Top 10 Training. [/highlight]

Description: Parsing the OWASP Top Ten with a closer look at Failure to Restrict URL Access

11 courses, 8+ hours of training

Learn cybersecurity from Ted Harrington, the #1 best-selling author of "Hackable: How to Do Application Security Right."

See Courses

11 courses, 8+ hours of training

Learn cybersecurity from Ted Harrington, the #1 best-selling author of "Hackable: How to Do Application Security Right."

See Courses

Introduction

Per our discussion of OWASP Top 10 Tools and Tactics, we continue our closer look at each of the Top Ten with deeper analysis and specific examples of these vulnerabilities. As I continue to convey each of these deeper dives out of sequence as defined by the Top 10, let's explore #8 in the name of randomness and chaos.

Eight on the 2010 OWASP Top 10 Web Application Security Risks is:

A8: Failure to Restrict URL Access

“Many web applications check URL access rights before rendering protected links and buttons. However, applications need to perform similar access control checks each time these pages are accessed, or attackers will be able to forge URLs to access these hidden pages anyway.”

As discussed in the parent guide for each of these deeper dives, I suggested tools to help you identify and mitigate these risks within your organization's web applications and services. For this particular discussion, I'll work through Failure to Restrict URL Access with Sensepost's Wikto given the additional features it offers beyond Nikto's functionality. We'll also discuss Shodan, a computer search engine.

Exploring Failure to Restrict URL Access

All standard web application testing caveats apply; it's always best to have permission to explore applications and sites that aren't yours.

How best to determine is a particular application is vulnerable To Failure to Restrict URL Access?

Straight from the OWASP Top Ten guidance: verify every page.

For each page, is the page supposed to be public or private? If a private page:

• Is authentication required to access that page?
• Is it supposed to be accessible to ANY authenticated user?
• If not, is an authorization check made to ensure the user has permission to access that page?

Ideally, external security mechanisms provide authentication and authorization checks for page access. It is recommended that you verify they are properly configured for every page; if code level protection is used you should verify that code level protection is in place for every required page.

Web application and penetration testing is clearly one of the best ways to verify whether proper protection is in place; here's where Shodan and Wikto come into play.

Shodan is "a search engine that lets you find specific computers (routers, servers, etc.) using a variety of filters. Some have also described it as a public port scan directory or a search engine of banners. The bulk of the data is taken from 'banners', which are meta-data the server sends back to the client. This can be information about the server software, what options the service supports, a welcome message or anything else that the client would like to know before interacting with the server"

As a result, Shodan might be useful to testers during the reconnaissance phase of a penetration testing engagement. The UI is straightforward and intuitive, and operators and filters are available as well.

As an example, imagine you're interested in discovering results for servers running Joomla in a specific country. A query such as joomla country:CN would result in Figure 1.

Shodan search results

Such results could then possibly used to feed Wikto with an IP address selected from valid Shodan findings.

Wikto (as implied by its name) is a Windows tool that is written in C# and thus requires the .NET framework.

Make sure to confirm your configuration and save it as a .wkt file for regular use. This will include defining locations for the Nikto Database and the Google Hack Database. As the default location for these files is C:Program Files (x86)SensePostWiktodatabases you'll need to run Wikto as administrator on Vista/Windows7/Windows Server 2008 when update these databases.

Once installed Wikto can be initialized via the Wikto Scan Wizard which will walk you through Target Selection, Configuration (proxy server if applicable), Confirm Settings, and an Overview. Alternatively you can use each Wikto tab as you see fit. Start with Spider and establish your target IP in the Target window along with a port if not a standard HTTP/HTTPS port. Continuing on our Joomla theme from above (now testing an approved test server), note that the Wikto Spider mined directories typical to Joomla, including /joomla and /stories as seen in Figure 2.

Wikto Spider results

Wikto is, first and foremost, a GUI for Nikto, so users can expect all related Nikto functionality. You'll find color coded severity ratings for each finding and deeper progression into the realm of discovered entities that can be classified under Failure to Restrict URL Access. Figure 3 ironically points out that perhaps /restricted. should be just that. ;-)

Wikto Nikto

The BackEnd feature set is where Wikto really shines for discovery of the Failure to Restrict URL Access issues. The BackEnd DB is provided by the Wikto developers (Sensepost) and includes a plethora of checks for directories, files, and filetypes that should not likely be left "unrestricted." Where the BackEnd tool discovers the likes of a directory such as /security as seen in Figure 4, exploration of such a finding might uncover additional issues such as "These XAMPP pages are accessible by network for everyone" as included in Figure 4. Ruh-roh, Rastro.

Wikto BackEnd

You may find the Google-related features somewhat hampered; this tool hasn't been updated in two and a half years, but it's still quite useful.

Summary

While we've explored Wikto don't forget the venerable Nikto as part of your Reconnaissance and Mapping phases of pen testing engagements. It's amazing what one can uncover with Wikto/Nikto; if the prescribed OWASP guidance is "the enforcement mechanism(s) should deny all access by default, requiring explicit grants to specific users and roles for access to every page" you'll quickly learn that more often than not, quite the opposite is default.

As always, let me know if you have questions via russ at holisticinfosec dot org.

Cheers, and good luck.