Photo: Photo Monkey

When I was in high school I was focused on being good at everything. Some time passed and I realized that successful people focus on one (1) aspect of their life and dive deep. Really Deep.

While approving my blog comments, I came across this:

I chuckled and thought, “Why would someone care about Cross-Site Scripting my site?”

Targeting My Site

Was someone trying to “hack” me to prove a point?

There are much more powerful and well respected bloggers than me in the information security realm. Why target me? If you want to gain visibility for your attack go after someone like Jeremiah Grossman, Billy Rios, Chris Evans, or Rafal Los. If you XSS their star on the walk of fame, you will generate some buzz. But it won’t last long. People’s memories are short.

Practice Before You Execute

When doing a presentation I prepare. I never was a boy scout, but being prepared is a way to feel confidant in what you do. I don’t like to “wing it.”

I prefer to start my presentation months ahead of time and keep focusing and refocusing it. Making the presentation tighter and tighter, until it is the best that I can do. Why do I prepare this much for a presentation maybe 10 people will see? To avoid embarrassment.

Presenting on something that you are unprepared for is the most excruitating thing I can imagine. It is my worst nightmare.

The person posting this comment did just that. They attempted to execute before they prepared.

Do Your Homework

I would like to give advice to the fledgling hacker. If you want to find XSS on a site, start by doing reconnaissance. Before typing in blindly to fields alert(123) do some research.

This site is clearly using WordPress. Download WordPress, install it, and Identify XSS attacks that you could launch on my site. Can’t find any? No problem. Start looking at the source code for XSS. Trust me, they exist.

Notes on The Attack

Comments need to be approved. So, even if this XSS was valid I would personally have to share it with my readers. In doing your homework, realize that other bugs, such as remote code execution, are WAY better. Look for those.

Return to Focusing

The next time you put things in perspective ask yourself, “Am I focusing on something I care about?” If the answer is yes, continue down the righteous path. If the answer is No, Find Your Purpose.

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.

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.

Photo: .m for matthijs

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.

Photo: Jens Finke - fotografie grafik verlag

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.

Photo: fpsurgeon

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

What is Insecure Cryptographic Storage

Insecure cryptographic storage occurs when an application doesn’t securely encrypt it’s sensitive data when it is stored into a database. This definition is similar to the picture above, recursive.

Simply stated, insecure cryptographic storage occurs when one of following happens:

1. The developers don’t encrypt the data that is being stored in the database.
2. The developers do encrypt the data being stored in the database, but they rely on encryption methods they have developed. (Also known as home-grown cryptography)

After reading these two points you may say, “only an idiot wouldn’t encrypt sensitive data being stored in the database.” I refer you to number two in the list above.

If you think you are smart enough to write your own cryptographic algorithms, you my friend, are the idiot.

The main business concern with not encrypting sensitive data is that it can lead to confidentiality loss. All companies are concerned with unauthorized individuals viewing their sensitive data. In addition, encrypting sensitive data is be a regulatory compliance. (See PCI-DSS requirement 3.)

An Example of Insecure Cryptographic Storage

Here is a simplified example. Selecting the users table from a database we are returned the following:

> select * from users;

The passwords in these table are 32 characters long. Could these passwords be MD5 hashes?

As with all hashing algorithms, MD5 hashes can’t be reversed. However, they can be pre-computed. Using a hash table lookup we can identify what the password is before it was ran through the MD5 hashing algorithm.

After inserting 5f4dcc3b5aa765d61d8327deb882cf99 into the online form the resulting password is returned. In this example, the password is “password.”

How Do You Prevent Insecure Cryptographic Storage From Occurring

If the data is sensitive and stored it NEEDS to be encrypted. Examples of items that are considered to be sensitive can include:

• Credit Cards
• User Names
• Passwords
• User data

There are other things to keep in mind when making sure you securely store information. This includes not creating your own cryptographic algorithms. No matter how smart you or your peers think you are DO NOT attempt to invent a new encryption algorithm. Leave this work to the experts.

Ensure that the data stored is not easy to decrypt. This can usually be averted by not using known weak algorithms such as RC3, RC4, MD5 and SHA-1.

If you are using asymmetric key encryption make sure to store your private keys carefully. If an attacker gets hold of the private key, you might as well not encrypt the data in the first place.

Photo: Rinoninha

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 thatSSL 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.

Photo: bitzcelt

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

What is Information Leakage and Improper Error Handling

Information leakage and improper error handling happen when web applications do not limit the amount of information they return to their users. A classic example of improper error handling is when an application doesn’t sanitize SQL error messages that are returned to the user. Upon receiving a SQL error message an attacker will immediately identify a place for identifying injection flaws.

Although preventing error messages from reaching users will not prevent vulnerabilities from occurring, it does make it difficult for an attacker to accomplish his goal and it is also an industry best practice.

An Example of Information Leakage

Common examples of information leakage include helpful error messages and service banners. Developers and system administrators often forget or disregard how something as simple as a server banner can be used by an attacker.

As an example, if your server is running Apache and you return the server header with your responses, an attacker could leverage this to fingerprint the version of the web server you are running.

Using nmap an attacker could send a few packets at your application server using the command, nmap -sV -p 80 192.168.1.100 and identify the following:

Interesting ports on 192.168.38.132:
PORT    STATE SERVICE  VERSION
80/tcp  open  http     Apache httpd 1.3.37

The attacker has now identified your Apache version and can now search for vulnerabilities affecting that version of Apache.

An Example of Improper Error Handling

Attackers attempt to leverage information that applications freely volunteer. If an application displays an error messages to the user (attacker), there is not guarantee that the user will “ignore” this error message.

Developers typically forget to properly handle their error messages. Stack traces and SQL errors are two examples of very commonly forgotten errors that should be handled.

Attackers love seeing error messages such as:

ERROR:  unterminated quoted string at or near "'''"

How Do You Prevent Information Leakage and Improper Error Handling

When developing applications, developers should assume all of the users are hostile. As a developer having this mentality will greatly aid you in developing secure applications.

All information returned from a web server should be reviewed for potential leakage. This can be automated by a QA team using a fuzzer.

Developers should also use a standard exception handling architecture to prevent information leakage from occurring. This architecture should be used and shared across the entire development team. All developers should handle their errors the same way.

Developers or product managers may also decide to create a default error handler which returns sanitized error messages for most users in production for all error paths. Doing this will greatly reduce the attack surface that can be exploited through error message generation.

Photo: Joe Penniston

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

What is Cross-Site Request Forgery (CSRF)

Cross-Site request forgery is a client-side vulnerability that allows an attacker to make requests on the user’s behalf. Although, most CSRF exploits require a user to be authenticated to the susceptible site to be successful, this is not always the case.

An Example of Cross-Site Request Forgery

A user (victim) opens their browser and logs on to their online banking application located athttp://bank.com

After checking their balance they browse away from the site (without logging off) and start reading web pages about olives from Madagascar. One of these olive sites is owned by an attacker. The attacker’s website has the following img src tag:

<img src="http://bank.com/transfer.asp?to_acct=445544&amount=1000">

When the victim’s browser loads the malicious page that contains this img src tag, the victims browser makes the transfer request (/transfer.asp?to_acct=445544&amount=1000) to bank.com using the authenticatedcookie from the earlier session. Upon making this request, the bank then transfers $1,000 from the victim’s account to account 445544. The attacker has now successfully executed a cross-site request forgery attack against a user of bank.com

How Do You Prevent Cross-Site Request Forgery

Any sensitive request that is generated by the user should force the user to “re-authenticate.” A simple example is that of change password functionality. You always want to verify the user knows the old password before changing their password, even if they are currently authenticated.

If you determine that “re-authentication” may be an inconvenience for the user or if all of your requests are considered sensitive then the application developers should include a random token that is unique to the user session. This token should not be present in the cookie, but rather as a hidden field in the HTML and then appended to the URL during any form submission.

When the attacker attempts to trick the users browser into making a request, the web application will look for this random token. The random token will not exist for the request, and the request will be denied. This prevents the CSRF attack from being successful.

Note: Having SSL does not protect your application from CSRF vulnerabilities.

Photo: tim_norris

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

What is Insecure Direct Object Reference

Insecure Direct Object Reference is when a web application exposes an internal implementation object to the user. Some examples of internal implementation objects are database records, URLs, or files.

An attacker can modify the internal implementation object in an attempt to abuse the access controls on this object. When the attacker does this they may have the ability to access functionality that the developer didn’t intend to expose access to.

Examples of Insecure Direct Object Reference

Insecure direct object reference is a very broad category of vulnerabilities. There are many examples of these types of vulnerabilities found in the wild by other names. Open Redirects and Directory Traversal are two classic examples of an insecure direct object reference vulnerability.

Open Redirect

This is where the web application has a parameter that allows the website to redirect the user somewhere else. If this parameter is not implemented properly using a white list, attackers can use this in a phishing attack to lure potential victims to a site of their choosing. More information about Open Redirects can be found here.

Directory Traversal

Assume a web application allows for a file to be rendered to a user that is stored on the local machine. If the application isn’t verifying what files should be accessed, an attacker can request other files on the file system and those will also be displayed.

For instance, if the attacker notices the URL:

http://misc-security.com/file.jsp?file=report.txt

The attacker could modify the file parameter using a directory traversal attack. He modifies the URL to:

http://misc-security.com/file.jsp?file=../../../etc/shadow

Upon doing this the /etc/shadow file is returned and rendered by file.jsp demonstrating the page is susceptible to a directory traversal attack.

How Do You Prevent Insecure Direct Object Reference From Occurring in Your Application
As always, web application developers can prevent these attacks through good planning.

Developers should use indirect reference maps. Direct mapping can easily be guessed by attackers. Developers should avoid exposing private objects to users. File names, external/internal URL’s, and database keys are all examples of things that should not be displayed to the user.

If direct objects must be used, then the developers should ensure through validation that the user is authorized to view what they are attempting to access. In the directory traversal example, determine what files the user should access and only grant them privileges to those files. This is known as an “accept known good” approach and is always a good idea when it comes to developing secure applications.

Photo: doug88888

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