Category Archives: Buzzwords

Security buzzwords heard out and about

Cross-Site Request Forgery (CSRF)

Photo: Joe Penniston

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 at http://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 authenticated cookie 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.

SQL Injection – Primer

Photo: XKCD

Photo: XKCD

SQL Injection is an injection flaw where a web application allows a user to send un-sanitized input into a SQL query.

The textbook example is that a web application has a username field that inserts the user’s input into the following SQL query:

statement = "SELECT * FROM users WHERE name = '" + userName + "';"

The user then types a' or '1'='1 into the username field. This creates the following SQL statement:

SELECT * FROM users WHERE name = 'a' or '1'='1'

If the statement variable is used for the authentication procedure then the evaluation of the SQL statement will always be true.

An attacker can cause damage if they appended something like, '; DROP TABLE users;--

This would produce the following SQL statement:

statement = "SELECT * FROM users WHERE name = ''; DROP TABLE users;--';

Which would result in the users table being deleted from the Database.

OWASP Top 10


When developing a security strategy for web applications many companies have no idea where to begin. The Open Web Application Security Project (OWASP) understood this problem and developed the OWASP Top 10.

The OWASP top 10 are the top 10 vulnerabilities that are found in web applications. This will begin a 10-part series dedicated to each of these vulnerabilities.

If you are a developer, you should understand these vulnerabilities. Understanding them is critical into introducing less vulnerabilities into your code.

The OWASP Top 10:
A1 – Cross Site Scripting (XSS)
A2 – Injection Flaws
A3 – Malicious File Execution
A4 – Insecure Direct Object Reference
A5 – Cross Site Request Forgery (CSRF)
A6 – Information Leakage and Improper Error Handling
A7 – Broken Authentication and Session Management
A8 – Insecure Cryptographic Storage
A9 – Insecure Communications
A10 – Failure to Restrict URL Access

Buzzword: FUD – Fear, Uncertainty, and Doubt

Photo: crowolf

Photo: crowolf

FUD is becoming a very common acronym to hear in security circles. The acronym FUD has been popping up on Blog postings, emails, tweets, and at security conferences.

FUD is an acronym that stands for Fear, Uncertainty, and Doubt. The phrase describes marketing schemes that are focused on using Fear, Uncertainty, and Doubt to sell a product. Good example of FUD are sensational headlines such as, “Conficker Now Instructed to Steal” or more famously, “Hackers Can Turn your Home Computer into a Bomb!

With FUD campaigns the marketer is attempting to use FUD to sell something. This marketed item could be a “security” product or FUD can be used to create a buzz around the “item at hand.”

One quick way to identify FUD is spotting a headline or article that is greatly sensationalized, has a lot of speculation, or makes gross generalizations. The other critical factor in FUD is there is a lack of information in the article. FUD articles clearly point out the problem, but fail to point out how the author arrived at this conclusion.

Fear, Uncertainty, and Doubt pray on human emotions and marketing campaigns that exploit this will not be going away any time soon.

XSS – Understanding Cross Site Scripting

If it hasn’t already, Cross-Site Scripting (XSS) will soon be replacing SQL injection as the new buzzword in the security sector. XSS will continually be a topic on this blog as well as others [1],[2],[3],[4]. Due to this fact, I think a primer would be a good idea for those who don’t know or understand this problem.

Many articles have been written about Cross-Site Scripting and if you want to have a better understanding of the problem, I suggest you read those documents (Links at the bottom of the post).

Basically, There are 3 types of Cross-Site Scripting:

  1. Stored/Non-Reflective/Persistent Cross Site Scripting (User visits the XSS’ed page)
  2. Non-Stored/Reflective/Reflected Cross Sited Scripting (User clicks a link that embeds the script into the loaded page)
  3. DOM Based Cross Site Scripting (please read this article)

All of these names make it confusing for a first timer to understand XSS. There really should be a better web application security standards organization. Here is a breakdown of Persistent XSS and Reflective XSS. These are the big two that most people talk about when they are referring to Cross Site Scripting. If you understand these well, you will be able to participate in 90% of XSS conversations.

Persistent Cross-Site Scripting
Persistent XSS is arguably more dangerous than reflective XSS. This attack embeds the malicious script permanently into the web application. The script will then wait until people access the page it is located on.

Here is an attack using Persistent Cross-Site Scripting:

  1. The victim visits a website they trust, amazon.com.
  2. A script has been inserted by an attacker on a page they happen to visit while on amazon.com.
  3. The script executes in the context of amazon.com.
  4. The victim is then compromised.

Note: Obviously, someone can increase the chances of the victim visiting this page (step 2) through social engineering, phishing, etc.

Reflective Cross-Site Scripting
These are the ones the media usually reports on. [1],[2],[3]. In this attack, some type of social engineering is involved for the attack to be successful.

Here is an attack, using Reflective Cross-Site Scripting:

  1. The victim gets an email/Instant Message that contains a link.
  2. The victim clicks the link. (Requires User Intervention)
  3. A script has been inserted by an attacker on the page they then visit.
  4. The script executes in the context of that site.
  5. The victim is then compromised.

Note: I want to reiterate that this attack requires some type of user intervention (step 2).

Why is Cross-Site Scripting Bad?
Cross-Site Scripting can lead to all sorts of different exploits, including system compromise. For an attacker to do this, they need to break out of the browser’s context. We have seen examples that breaking out of the browser is not that hard to do.

In addition, an attacker can also establish a bi-directional channel using iframes. This creates a man-in-the-middle attack. The attacker can then intercept key strokes, use the victim as an intranet portscanner, and even stealing creditials. The attacker is only limited by their knowledge of scripting.


Example of a bi-directional channel

Hopefully, this gives you a better understanding of Cross-Site Scripting. Feel free to leave comments if you don’t understand something and I will address it in the article.

Additional Resources:
Cross-Site Scripting (XSS) FAQ
OWASP Guide to XSS
XSS tutorial
XSS Video Tutorial (via youtube)
XSS Attack API

Buzzword: Managed Services

What is the word most likely to be heard at a non-technical security conference? If you said, “Managed Services,” “Managed Information technology services,” “Managed Solutions” or some variant of it, then you have been spending too much time at security conferences.

Managed Services is the idea that you take some piece of your company and have someone else do it. Companies typically take something that is expensive for them to do and then outsource it. For instance, most large companies pay an accounting firm, such as a Big 4,  to do their taxes instead of having a dedicated tax department. This of course is an analog managed service, and is sometimes regulated by compliance. Another analog managed service would be a law firm.

The type of managed service this article is referring to is a digital one. The idea that you can pay someone to outsource some piece of your general solution. That could be web hosting services or security services.

Although managed services is not a new idea, it is gaining snow-ball style momentum. There are, of course, companies who have built their entire model on Managed Services such as Savvis and Akamai. More recently, larger companies are jumping on the band wagon to also offer managed solutions. These companies include, AT&T, BT, and an unlikely candidate Amazon with their S3 cloud/EC2.

So, if you want to make sure your company can play with the big boys, make sure you have a managed service solution.

Note: Totally off topic from the Buzzword itself is the site, www.managedsoultion.com. They cashed in on the buzzword and actually named the company after the buzzword. I am going to start making a note on each buzzword to see if any other companies have done the same. Great Marketing!

Buzzword: Compliance

Photo: Noël Zia Lee

Photo: Noël Zia Lee

Compliance is not a new buzzword, in fact in other industries compliance has been around a long time. During the RSA conference, every vendor had the word compliance on their cardboard bulletin board, an adult version of a diorama. [1]

What are the different types of compliance?

In computer security, compliance began with the government. This is where all good ideas come from (sarcasm). Over time compliance regulations evolved into something that was “needed” by the industry to make sure that corporations took steps to protect their user’s data. It is sad that corporations need an intervening body to tell them that they should secure their data. However, this is why HIPPA and SOX came about. Why should a hospital spend money to protect patient’s records? That is crazy talk!

I have been in the security community for a long time and I hate to tell you but companies will never care about security. They will do the minimum thing required in order to satisfy the masses. In the U.S. the only thing that matters is the bottom line. Companies pay for Cost-Benefit analysis on things to determine what the corporate strategy should be. Corporations don’t do this because they care about the result, they do it to save money, thus being profitable for their shareholders.

If the only thing that matters is the bottom line, you need independent regulatory agencies to mandate certain rules for the greater good.

As long as consumers believe that the products they buy are safe, they will continue to buy them.

Let’s take the protection on a container of Tylenol. In 1982, a bunch of people were poisoned in Chicago because someone decided to put potassium cyanide in random bottles of Tylenol. What was the result of this? The market share of Tylenol dropped from 35% to 8%. It took an entire year for Johnson & Johnson to grab the market share again. They did this by creating a triple-sealed package and dropped their cost to be more competitive. After this Johnson & Johnson grabbed more market share than they had before!

In this example, the consumer stopped trusting that Tylenol was safe and subsequently stopped buying Tylenol. They didn’t stop buying medicine just Tylenol. The attacker could of poisoned other bottles too, but that didn’t matter. What the customer cared about was the safety of a product. When the consumer felt good about Tylenol again, they begin buying the product again.

The purpose of compliance is to make the consumer feel safe. The government needed to step in and mandate in order to have the people feel protected.

Does compliance work?

It depends on who you ask. Mike Bailey doesn’t think so. However, others do. For instance, Companies that make profit from compliance defiantly think it works.

Why is compliance so often talked about?

Companies that do cost-benefit analysis like the ones above need to be compliant. They will comply the cheapest way they can, thus keeping their operating costs low. Companies will continue to offer cheaper and cheaper compliance products. Just remember, they get what they pay for.