Disclaimer

The words and opinions expressed here are those of each article's respective author, and do not necessarily represent the views of CapTech Ventures.

Management Consulting

Secure Development - Cross-Site Request Forgery (CSRF)

Last week, we talked about Cross-Site Scripting (XSS) and briefly touched on Cross-Site Request Forgery (CSRF). These two attacks are very common and dangerous, which explains why they consistently rank among the top five web application vulnerabilities in almost all recent studies. This week, we'll go into more detail on CSRF. First, a quick reminder about the difference between these two attacks: XSS involves injecting unauthorized code into web pages, while CSRF involves making unauthorized requests that appear to come from a legitimate, logged-in user. Another way to think about the difference is that XSS abuses the user's trust in the web application, while CSRF abuses the trust of the web application in the user.

Secure Development - Cross-Site Scripting (XSS)

Originally, this week's post was supposed to cover both Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF), but I quickly realized that each of these topics alone are more than enough to fill a blog entry. These two are some of the most common and dangerous web application attacks, and at first glance, it may be hard to tell the difference. Here is an easy way to distinguish them: XSS involves injecting content into an existing page, while CSRF involves taking unauthorized actions on behalf of a logged-on user. XSS can be used (and often is) to launch CSRF attacks, but they are two separate attack modes.

Secure Development - ShmooCon Edition

This week I'm taking a break from my current series of top 10 web application vulnerabilities. Instead, I'll be talking about my experiences at ShmooCon (http://www.shmoocon.org/), an annual IT security conference in DC that has a very similiar feel to the (in)famous DefCon. As usual, ShmooCon was a whole-weekend experience, with lots of things going on besides the official talks: many different contests, vendor booths, lock-picking tutorials, you name it... Throw in about two feet of snow that fell in DC the Saturday of the con, and things start becoming even more interesting! In fact, I was very lucky to get out of town on Monday thanks to a fellow CapTecher who was headed back to Richmond by car.

Secure Development - Injection Flaws

Welcome to the second post in my series on secure development issues. This week's topic is injection flaws, including SQL and command injection. The most common types of web application injection flaws include:

  1. Database systems: SQL injection (e.g. 1=1)
  2. Script languages such as Perl, Python, JavaScript
  3. Shells for external commands (e.g. ; rm -rf /)
  4. Calls to the operating system via system calls
  5. Path traversal in file names (e.g. ../../etc/passwd)

Let's look at an example of a typical SQL injection attack: Let's say a developer writes the following Java code to build an SQL query to authenticate users.

var query = "SELECT * FROM users WHERE user = '" + username + "' AND password = '" + pwdHash + "'";

If an attacker enters the following into the input form, he can bypass authentication completely:

Effective Communication Through a Requirements Document

After reading Chris LaCroix’s blog entry on Requirements gathering (see Five Things Analysts Should Always Do To Ensure Success), I was reminded of a previous assignment where two things I had learned long ago were reinforced.  The first was a mantra preached by a senior Business Systems Analyst:  “You can never have too much detail in your requirements”.  The other was “A picture is still worth a thousand words”.  They both fit together into one statement:  Requirements must be communicated effectively, in a way that is easy for everyone to understand.