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: 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

Reading time: 2 – 3 minutes

Photo: Jason Arends

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

What are Insecure Communications

Insecure communications is when a client and server communicate over a n0n-secure (non-encrypted) channel. By doing this, the developer is ensuring that their communication channel can be viewed by eyes they didn’t intend.

Failing to securely communicate server-to-server and server-to-client helps attackers to intercept sensitive transactions. Attackers do this by using man-in-the-middle attacks, a post for another time. Not communicating securely breaks down confidentiality and integrity.

Developers fall into communicating insecurely when they:

• Don’t secure their client-to-server connections.
• Don’t secure their server-to-database connections.
• Don’t secure other back end connections that pass sensitive data.

An Example of Insecure Communications

Assume a developer has written an application that takes input from a user and stores it in a database that is located on another network segment.

If the developer fails to use SSL between the web server and the user, then he has an insecure communications channel between the user and the web server. (Client-to-server connection)

If the developer fails to forget to encrypt the connection between his web server and the database, then he is failing to secure the server-to-database connection.

How Do You Prevent Insecure Communications from Occurring in your Web Application

To prevent insecure communications from occurring, the first step is to make sure the security architect has formulated secure methods of communication between the clients and servers. The security architect can limit the connections they need to look at by only reviewing which servers and clients pass sensitive data.

Keep in mind, most of these architectures will fail to forget to encrypt data on back-end connections, such as database connections. Just because the data is now behind a firewall doesn’t mean it should be passed in clear-text.

To verify insecure communications won’t happen on your network:

• Make sure all client-to-server connections are encrypted with SSL.
• Verify that server-to-database connections are encrypted.
• Verify that any other areas in the design where sensitive data is passed is done so in a secure way.
• Keep developers in a security mindset. Developers should never assume their application is sending their information securely. Developers should always assume that any communications that are being made are done insecurely.