1. Error messages enabled
2. Cross-Site Scripting (unescaped input)
3. And yes, SQL Injection of some sort

The (un)fortunate thing is that most of these issues are easily solvable. A generic error page, as opposed to a stack trace or verbose error message, can usually be implemented with a couple configuration changes. Yet, I still see large websites that spit out stack traces and code when an error occurs.

Cross-Site Scripting is another issue that still plagues us. Testing for it is simple – just enter something like test"> into an input field and if the resulting page displays that in raw HTML, chances are you have a problem. Every language has some form of HTML-escaping function and, if possible, it’s good to turn this on by default. This will be the case in Rails 3.0, thankfully.

Finally, I still see traces of SQL Injection on an all-too regular basis. Identified by the oh-so-dangerous single tick mark – ‘ – and typically resulting in an error page that shouldn’t be showing up anyway if the first issue were address. That said, even if the error is obscured, it’s still possible to retrieve data using a technique called Blind SQL Injection. Any data getting sent to an SQL server should also be properly escaped or sent through stored procedures depending on the backend technology. Think SQL Injection isn’t a problem? Talk to RockYou, whose database of 32 million usernames and passwords was compromised because of it.

Address those three things and (sadly) you’ll be ahead of the game.

Over the course of the past few months, as I’ve been involved with my own startup, I’ve been paying a lot more attention to that industry. With a quick and dirty development model, it’s often easy for devs to overlook security. Although some frameworks address a lot of the usual concerns (SQL Injection, XSS), they are susceptible as well.

Let’s take a look at a couple examples that enterprises such as Microsoft and Google now understand, that small development teams might not.

1. Put an email address on your website.

Yes. I’m serious.

I’ve come across several issues on startup sites recently and being the responsible security researcher that I am, have wanted to report them. Spending a half-hour spidering the site trying to find a single contact email is a lose-lose situation. I’m either going to discard the bug and the site will remain vulnerable, or somebody else will publicly disclose it and the typical ‘hair on fire’ scenario will ensure.

2. Respond to the email.

If you don’t respond, I have no clue if you’re addressing the issue. A timeline for a potential fix might also be nice, but not always necessary.

Additionally, security researchers generally like the cred associated with finding a bug (ego boost and resumé builder, you know?). So if you do make an update and have some release notes, why not thank the researcher for preventing your hair from catching on fire more than it already is?

3. Don’t write off the security guy.

6 years ago, there was a large back-and-forth on a Mozilla bug. This year, it was confirmed as a vulnerability known as clickjacking. That Mozilla thread is a pretty classic example of the security disclosure process. If a security researcher is writing to you to report a vulnerability, engage in conversation to understand the concern. Yes, we do sometimes get a little paranoid. But if we emailed you, we’re really just trying to help.

4. Don’t sue the security guy (aka have a disclosure policy).

One reason that I frequently hold off on reporting bugs I may come across is that I can’t find a disclosure policy on the site. As an example, both eBay and Microsoft allow for easy reporting of security vulnerabilities. Most sites, however, don’t and it has happened in the past where a security report has been misconstrued as “hacking”. Providing some assurance that this sort of action won’t be taken or an easy means to report vulnerabilities will open up the communication channel necessary.

Hopefully these short notes will help small companies become more open and willing to accept security bugs from external researchers. Occasionally, we come across issues in the course of our normal web activity and wish to report them. Having a published and easy means of doing this is important in allowing for this communication.

The evolution of JavaScript and its place in security perfectly parallels the transition from server-side security to client-side security.

~History~

Before network firewalls were commonplace, the juiciest targets to go after were servers. In what is now unthinkable, it was common for systems to be deployed directly on the Internet with no firewall whatsoever. This is part of the reason that Code Red, Nimda, and Slammer were so successful. The opposite is true now. Network firewalls are commonplace, Windows XP has the firewall turned on by default, and Server 2008 will be the first Microsoft Server OS to be deployed with the firewall enabled by default. As such, attackers moved on to the next target – client workstations and the primary way users interact on them.

~/History~

So why should you, as a startup, care about all this? Two reasons.

1. Protect your site from common attacks
2. Protect yourself from being a victim

To address the first one, there’s a common attack known as Cross-Site Request Forgery. I’ll get into it in more detail in another post, but effectively it allows one site to take action on another if that target site has not put effective controls in place. A common mitigation is ensuring that all data modification methods occur via POST requests (per HTTP standard). However, if you don’t have tokens associated with those POST requests, another site could utilize javascript to craft and submit fake POST requests to take actions on a logged-in users behalf. Does your site have a “remember me” checkbox? Do user sessions not time out? This could be a problem for you. This issue has been widely known for at least four years (Chris Shiflett on CSRF), but it’s only recently been gaining a lot of attention. I’m surprised more frameworks don’t have protection for this enabled by default, but it could likely impact development testing. The general approach to fixing this is by utilizing some sort of server-generated token that’s inserted as a hidden form field and verified on user submittal.

To address the second, an example is necessary. JavaScript, for the most part, is fairly essential to a number of sites that you may visit on a regular basis. The danger however, is malicious JavaScript that may get executed without you even knowing it. That script could be on that site and trying to take action on a different site, or sourced from a remote site altogether. Take, for example, poor David Airey who lost his domain due to a GMail CSRF vulnerability. The basics behind the attack are as such: At one point, David visited a page that had a malicious JavaScript. That script posted back to his GMail account, reconfiguring it so the attacker could hijack emails. That reconfiguration including forwarding and deleting all domain-related emails. Once David went on vacation, the attacker went to work and David lost his domain.

So how can you protect against this second attack? I personally make use of the Firefox extension NoScript. This handy extension prevents JavaScript code from automatically executing when you visit a web page, unless you’ve previously whitelisted that site. While it can be a little annoying, it’s much better than unknown JavaScript executing in the context of my browsers…where I spend a good majority of my day.

• Search Forms

  Search forms generally re-display the search term entered by the user. These terms are quite frequently not properly encoded, either, leading to Cross-Site Scripting (XSS) attacks.

• Jobs and Events

  Jobs and Events pages frequently utilize a database behind the scenes to manage job postings and event listings. Further, they’re usually pretty easy to check as they have the job or event id in the URL for page rank, etc. I’ll commonly look for these for easy injection vectors.

• Cookies

  Utilizing the fantastic Web Dev extension, I’ll take a quick look at the cookies. If I see anything more than a session ID, I’ll start modifying and manipulating the cookies to verify that server-side checks are in place. Cookies can also frequently lead to XSS.

• Hidden Form Fields

  If there’s a contact page with a form, the first thing I do is look for hidden form fields to see what parameters the web developers might have thought that a user wouldn’t see by putting them in a “hidden” field. I’ve come across everything from spam gateways to arbitrary file access due to simple issues like this.

• Typical Directory Structures

  Finally, I’ll commonly poke around in typical directory structures to see if I get lucky. Things like /admin/, /logs/, and /config/, among others, often are not intended for public consumption or linked to, but are present on the site.

There you go – those are generally the first places I look if I need to take a quick look at a web site. Beyond that, I start digging into more complex input locations within the application, logic happening behind the scenes, and potential user authorization issues.

PCI Compliance

PCI Compliance has probably been one of the strongest driving factors of security compliance in the US in recent years, particularly for retailers. So what is it? PCI stands for Payment Card Industry and the PCI Data Security Standard is an accepted standard among the payment brands (Visa, MasterCard, Amex, Discover, etc) that defines a set of 12 requirements that merchants who handle cardholder data must be compliant with. *you can breathe now* With that broad statement, there are a few things to point out.

Cardholder Data

Straight from the PCI website…

Cardholder data is defined as the primary account number (“PAN,” or credit card number) and other data obtained as part of a payment transaction, including the following data elements:

• PAN
• Cardholder Name
• Expiration Date
• Service Code
• Sensitive Authentication Data: (1) full magnetic stripe data, (2) CAV2/CVC2/CVV2/CID, and (3) PINs/PIN blocks)

This effectively means that if you store, process, or transmit a credit card number, alone or in combination with the data listed above, you are subject to PCI DSS. I should note, however, that there are different requirements based on your size and processing volume and you should contact your acquirer, payment brand, or local Qualified Security Assessor (QSA) to determine your PCI DSS validation requirements.

The Requirements

So, 12 requirements, huh? Yup. Each with several sub-requirements, too. While you can read the details on the PCI DSS site (click “Download the Specification”), I think it’s more important for startups to realize that there are very specific requirements surrounding the handling of cardholder data and to consider those requirements when extending into such areas as e-commerce. Ultimately the goal is to manage the risk of storing cardholder data by means of network segregation, data encryption, audit logging, policy and security testing (among others). Options are also available for outsourcing credit card transactions, which can relieve the strain of PCI compliance for a startup.

One More Thing

Are you a software developer building a payment application but not actually storing cardholder data yourself? You still need to be aware of PCI and the Payment Application Data Security Standard. This ties in to my previous post about third-party components and is PCI’s attempt to ensure safe handling of credit card data for payment applications created by software vendors.

Your site is only as secure as the software you install.

I’ll be posting some more info regarding some work I’ve done in this area recently, but I did want to make a quick post about the security of third-party components.

When you download that plugin or code written by somebody else, are you doing a sanity check to make sure it’s secure? Here are a few quick things to think about in order to identify the attack surface.

• Does it write to disk?
• Does it communicate with the database?
• Does it interact with the user?

Why should you be asking these questions? To determine if it protects against the following attacks.

• Can I modify the file that it reads/writes to?
• Does it protect against SQL Injection?
• Does it sanitize or validate input?

Security should definitely be a concern when installing any third-party components or plugins on your site. While it’s difficult to verify the security of external code, you can at least do a quick profile of it and understand what your primary risks are as noted above. A perfect example is the recent WP Comment Remix Security Bulletin – installation of that plugin allowed for both SQL Injection and Cross-Site Scripting.

Let’s take the example of a staging site. Frequently made Internet accessible for testing purposes, staging sites are a perfect example of the gap between typical web users and more curious, perhaps malicious ones. While typical users will go to x.com and completely interact with the application there, it is not outside the realm of possibility for a curious individual to try staging.x.com, a well-known scheme for staging sites. If this exists, it could reveal information to a potential attacker through verbose error messages or debug information. Besides simply making this public available, here are a couple other flaws I have seen on live staging sites.

1. Having debug information available

   One startup allowed users browsing to their staging site to set a cookie that showed debug information. This debug information included exact SQL statements that were getting sent to the database. Having this information readily accessible could provide an attacker with the information needed to craft a custom attack.

2. Not locking down all avenues

   After it was publicly disclosed, this same startup restricted access to that staging site using basic authentication. Verifying this out of curiosity, I tried to access it via HTTPS. To my surprise, I was not prompted for authentication.

Another common problem is that of putting a site online in the early stages of a startup. Maybe you need to demo the site to a potential investor or client. Maybe you have outsourced some testing. In any case, the one thing to remember is that if you open a port to the Internet, it’s not private. Port scans, especially for web servers, are extremely common. Combine that with the re-use of IP addresses (*cough*The Cloud*cough*) and your “private” site may be crawled by search engines within the hour. I’m sure most of you are familiar with the statistic that an unpatched XP system only lasts 20 minutes on the net without being found and compromised. If you do restrict access to this, here are a few things to remember.

• Use strong passwords

  When encountered with an authentication prompt of an application that I’ve been hired to review, some of the first things I try are:

  1. admin/admin
  2. guest/guest
  3. demo/demo
  4. Names of, or relating to, the site or application
  5. And a few more…

  You may or may not be surprised with the number of “protected” sites I’ve been able to gain access to by applying this simple logic.

• Use multiple layers, if possible

  A combination of authentication techniques is much preferred to only one. For example, usernames and passwords can be shared and frequently are. IP filters will help limit where access is allowed from and is a very effective method of restricting access.

• Know your external attack surface

  Only by knowing what services or servers you have Internet accessible, can you adequately address the potential risk.

Maintaining infrastructure is not an easy task, but limiting access to exposed services can help limit the risk to an environment. Beyond that, keeping up-to-date on security patches, applying them in a reasonable time frame, and applying common sense security to system administration are all very important. When the environment becomes larger, the toolset necessary to manage these different aspects also becomes important.

And what I’m finding is a little disappointing.

Perhaps I’ve become a little jaded in the past few years as a security consultant. Working with some large organizations where people usually “get” security makes most (yes, there is definitely still a decent level of feedback) conversations surrounding security fairly straightforward. Not only that, but large organizations generally have the benefit of staff that understand security risks and can effectively merge them with the desires of the business to reach a reasonable solution. But let’s take a brief tour over what I’ve come across recently. (Names left out to protect the innocent.)

Exhibit 1 – A random startup (Company A) allows signups on its web page. As with any new service, I’m sure reporters would have liked to have seen who was signing up from what companies, particularly in order to validate Company A’s claims of rampant success and signups. Company A, unfortunately, would display a users’ email address on the confirmation signup page. That confirmation signup page had a parameter that could be incremented up or down to reveal email addresses of anybody that signed up.

Class: Basic design flaw, forced browsing.
Status: Fixed, within a half-hour of reporting.

Exhibit 2 – Another random startup (Company B) has a new service that claims to solve some of your email woes. One of the features of this service is that you can subscribe to RSS feeds of your Inbox. Unauthenticated RSS feeds. Yes, yes, there’s a SHA-256 hash in the URL, but both Google Reader and Bloglines are searchable, not to mention the potential for referral sniffing or just plain information leakage issues.

Class: Design flaw, lack of authentication.
Status: Removed, within a half-hour of reporting. Put back into place using HTTPS. Authentication still not used.

Exhibit 3 – Company C has a sweet iPhone app. They also have a web page that is somewhat integrated into the application. That web page is vulnerable to SQL Injection.

Class: Input validation, SQL Injection.
Status: Reported, twice. No response. Depression ensues.

Exhibit 4 – Company D releases an update to their product and is highly regarded as their service no longer requires the installation of an additional component. Unfortunately, the new feature that permits for that is Cross-Site Scriptable.

Class: Input validation, Cross-Site Scripting.
Status: Reported on October 13. Waiting.

I guess what depresses me is that some of these are pretty basic issues. With all of these problems, I came across them within 5 minutes of using the application. I suppose this post is a plea to the startup’s of the world…

Please, if you aren’t familiar with security, take the time to either talk to somebody that is or bring in a security person for even just half a day to take a look at your product. If nothing else, it’s one less fire that you’ll have to put out. You can even contact me directly if you’re not sure what questions to ask, although I’ll probably put a post up about that at some point.

Granted, the statement above applies to everybody as even Russ McRee frequently points out on his HolisticInfoSec blog, many other organizations struggle with basic security flaws regardless of their size or status.

1. Look and feel

   Honestly, if a web application looks like it was coded using a GeoCities or Frontpage template, chances are pretty good that it was coded by a developer with little experience. What that means, in turn, is that there are likely to be common security issues throughout the site.

2. Error handling

   Somewhat related to the point above, how does the site handle application errors? Does it spit out a verbose error message with a stack trace? Or does it gracefully handle the error message and display a generic message or redirect the user appropriately. Error messages are an attacker’s friend.

3. Parameter Fields

   What kind of parameter fields does the site use, particularly in the URL? If numeric, are the parameters relative to the user or global to the application? Do file names get passed in as parameters? If so, those might susceptible to path traversal issues. Is there a routing protocol on the front-end that limits the input, or do parameters get passed to server-side code to verify format?

4. Invalid user input

   How does the application react when I enter input that is invalid? By invalid, I mean everything from attempting to access data that isn’t mine to putting in a name in a telephone field. Depending on this, I can gauge how much effort was put into validation and sanitization.

5. Reflected user input

   Related to the point above, how does the application display user output. If I type HTML characters in a search that are then displayed on the results page, are they HTML encoded? Django 1.0 automatically takes care of this by autoescaping all output, for example, but other frameworks don’t.

If the developers haven’t thought about these few things, it will be painfully obvious. If they have, I know that it’s going to be more difficult to find problems and they will usually be *logic errors* or *infrastructure issues*.