Entries Tagged "SQL injection"

Page 1 of 1

SQL Injection Attack on Airport Security

Interesting vulnerability:

…a special lane at airport security called Known Crewmember (KCM). KCM is a TSA program that allows pilots and flight attendants to bypass security screening, even when flying on domestic personal trips.

The KCM process is fairly simple: the employee uses the dedicated lane and presents their KCM barcode or provides the TSA agent their employee number and airline. Various forms of ID need to be presented while the TSA agent’s laptop verifies the employment status with the airline. If successful, the employee can access the sterile area without any screening at all.

A similar system also exists for cockpit access, called the Cockpit Access Security System (CASS). Most aircraft have at least one jumpseat inside the cockpit sitting behind the flying pilots. When pilots need to commute or travel, it is not always possible for them to occupy a revenue seat, so a jumpseat can be used instead. CASS allows the gate agent of a flight to verify that the jumpseater is an authorized pilot. The gate agent can then inform the crew of the flight that the jumpseater was authenticated by CASS.

[attack details omitted]

At this point, we realized we had discovered a very serious problem. Anyone with basic knowledge of SQL injection could login to this site and add anyone they wanted to KCM and CASS, allowing themselves to both skip security screening and then access the cockpits of commercial airliners.

We ended up finding several more serious issues but began the disclosure process immediately after finding the first issue.

Posted on September 2, 2024 at 7:07 AMView Comments

How to Write Injection-Proof SQL

It’s about time someone wrote this paper:

ABSTRACT

Googling for “SQL injection” gets about 4 million hits. The topic excites interest and superstitious fear. This whitepaper dymystifies the topic and explains a straightforward approach to writing database PL/SQL programs that provably guarantees their immunity to SQL injection.

Only when a PL/SQL subprogram executes SQL that it creates at run time is there a risk of SQL injection; and you’ll see that it’s easier than you might think to freeze the SQL at PL/SQL compile time. Then you’ll understand that you need the rules which prevent the risk only for the rare scenarios that do require run-time-created SQL. It turns out that these rules are simple to state and easy to follow.

EDITED TO ADD (10/26): Never mind; this seems to be a self-serving marketing piece.

Posted on October 16, 2008 at 5:56 AMView Comments

Oklahoma Data Leak

Usually I don’t bother blogging about these, but this one is particularly bad. Anyone with basic SQL knowledge could have registered anyone he wanted as a sex offender.

One of the cardinal rules of computer programming is to never trust your input. This holds especially true when your input comes from users, and even more so when it comes from the anonymous, general public. Apparently, the developers at Oklahoma’s Department of Corrections slept through that day in computer science class, and even managed to skip all of Common Sense 101. You see, not only did they trust anonymous user input on their public-facing website, but they blindly executed it and displayed whatever came back.

The result of this negligently bad coding has some rather serious consequences: the names, addresses, and social security numbers of tens of thousands of Oklahoma residents were made available to the general public for a period of at least three years. Up until yesterday, April 13 2008, anyone with a web browser and the knowledge from Chapter One of SQL For Dummies could have easily accessed—and possibly, changed—any data within the DOC’s databases. It took me all of a minute to figure out how to download 10,597 records—SSNs and all—from their website.

Posted on April 18, 2008 at 6:16 AMView Comments

Sidebar photo of Bruce Schneier by Joe MacInnis.