Miscellaneous Security

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: Mrs. Magic

When testing web applications, penetration testers should look at how the session is handled. Session management is commonly overlooked by developers and system administrators. It is so often overlooked that it is one of the OWASP Top 10, refereed to as “Broken Authentication and Session Management.”

This article will cover certain attributes that cookies typically have. In the future we will address how to use attribute tags to help aid developers in securing their applications. This article assumes the reader has a basic understanding of what a cookie is.

Here is a sample HTTP response. This is what the server responds with after a client request is made. The response has been edited for brevity.

HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: session=YnJldHQ6bXlwYXNzd29yZA==;expires=Thu, 30 Dec 2037 00:00:00 GMT;path=/;domain=.misc-security.com
Content-Length: 8400

For those unfamiliar with cookies, a cookie consists of a name/value pair. In this case the cookie name is “session” and the cookie value is “YnJldHQ6bXlwYXNzd29yZA==”

Following the cookie name/value pair are the attribute/value pairs that apply to that cookie and are delimited with a semicolon. In this example their are three attribute/value pairs: expires, path, and domain.

Expires Attribute

expires=Thu, 30 Dec 2037 00:00:00 GMT

The expires attribute is used to tell the browser when the cookie should no longer be used. Browsers will cache this cookie locally until the expires date is reached. When the expires date is reached the browser will stop sending the cookie after the browser is closed. In our example the cookie will remain valid until December 30th, 2037.

Path Attribute

path=/

The Path attribute specifies the subset of URLs to which this cookie applies. In this case, the cookie will be sent for any request to this server. If a user requests /bobsapp/ or /tomsapp/ this cookie will be sent.

Domain Attribute

domain=.misc-security.com

The Domain attribute specifies the domain for which the cookie is valid. An explicitly specified domain must always start with a dot. In our example, this cookie will be sent to misc-security.com and any sub-domains of misc-security.com (e.g. asparagus.misc-security.com).

In a future article we will continue looking at the attribute/value pairs that cookies can have and will even revisit these attributes explaining how each needs to be understood to securely handle a user’s session.

Further Reading:

RFC 2109 – HTTP State Management Mechanism
RFC 2965 – HTTP State Management Mechanism (New Version)

Reading time: 3 – 4 minutes

Photo: Stephen Poff

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

What is Broken Authentication and Session Management

When developers are programming web application based solutions they rarely focus on how the user’s session is managed. Failing to keep this in mind can lead developers to introduce session management vulnerabilities in their applications.

Session management vulnerabilities occur when developers fail to protect their users sensitive information such as user names, passwords, and session tokens.

Broken authentication vulnerabilities occur when developers fail to use authentication methods that have been adequately tested and rely on their own, often flawed, method for authenticating users.

These vulnerabilities are very hard for developers to identify on their own due to the far-reaching aspect of the code that handles session and authentication.

An Example of Broken Authentication and Session Management

Due to the broad reach of this vulnerability there are many examples of broken authentication and session management occurring. Examples include forgotten password functionality, emailing user credentials, relying on IP address for session, not authenticating a user before changing a password, and not having adequate timeouts for inactive sessions.

Forgotten Password Functionality

Web applications often have a forgotten password functionality that allows a user to submit their user name to the application and are taken to a page with secret questions or a temporary password reset function.

Attackers can exploit this functionality to enumerate valid user name for the application. Developers often forget that a user name is half the puzzle to an attacker. Is an attacker knowing a password damaging if they don’t know a user name to go along with it?

How Do You Prevent Broken Authentication and Session Management

Protecting credentials and session cookies is one of the most difficult tasks for a developer. Protecting this critical pieces of data can touch on many lines of code in several different files.

To prevent these types of vulnerabilities from occurring in your application, developers should first ensure that SSL is used for all authenticated parts of the application. In addition, verify that all credentials are stored in a hashed form.

As with all prevention methods preventing these vulnerabilities takes careful planning from the design stage of the application. The following should all be considered:

• Only use the native session management mechanism. Do not write your own session handlers. Do not use home-grown cookies for authentication or session-management.
• Use a single authentication mechanism. Again, do not write your own authentication mechanism.
• Do not allow the login process to happen from an unencrypted page.
• Once a user authenticates, issue them a new session cookie and invalidate the previous session cookie. This will prevent session hijacking attacks from occurring.
• Verify that every page of the application has a logout link that is easily identified by the user.
• Have adequate timeouts for inactive sessions. Shorter is better.
• Verify the user knows their old password before changing their password.
• Do not send credentials (including the user name) over insecure channels, such as email.
• Do not expose session identifiers, such as the session token, in the URL.