Biscom Delivery Server » hacking

How to protect against SQL injection

bho1 — Mon, 20 Dec 2010 20:47:26 +0000

SQL injection is still out there as an attack. It worked against Twin America LLC, and it was only discovered this past October, after hundreds of thousands of records were stolen. It’s a well known ploy – you take advantage of web sites that have a form for inputting information. If a site doesn’t employ techniques to nullify SQL injection, an attacker can easily see your entire database, which often includes usernames, passwords, and account information, or worse, download the information and then destroy the database.

Two common areas that are potentially open to attack are unfiltered escape characters, and poor type handling. In an unfiltered web form, a form variable is plugged directly into a SQL statement. If I crafted just the right input, I could potentially append my own SQL clause to the one being executed. The classic example is:

SELECT * FROM user_table WHERE username = ‘ ” + username + ” ‘;”

If instead of a valid username, I entered ‘ or ’1=1, I’d now be running this statement:

SELECT * FROM user_table WHERE username = ‘ ‘ OR ’1′=’1′;

The OR ’1′ = ’1′ clause will always evaluate to true, retrieving all columns from the user table.

A second potential hole exists if the programmer does not check for type constraints. If a SQL statement is expecting a number, the input to supply that variable should be checked to make sure it truly is a number. Again, like the trick above, I could insert an entirely new statement like DROP TABLE user_table after entering a number into a form. The back end would then execute whatever statement I presented to it.

There are several techniques to protect a Web application from these types of attacks, including the use of parameterized statements, or even escaping characters that have a special meaning in SQL. But programmers have to be diligent about adding this protection, because hackers will find even the smallest hole and take advantage of it.

Biscom spends its time worried about these types of hacks, so you don’t have to. Countless penetration tests have proven our security model. We think our customers want a secure file transfer solution that is actually secure.

RSA Conference 2010

bho1 — Mon, 08 Mar 2010 16:33:45 +0000

Just got back from the RSA conference in San Francisco last week. It was quite a show — some heavy hitters were in attendance, including Secretary of the Department of Homeland Security Janet Napolitano, FBI director Robert Mueller, and a very cryptic NSA spokesperson. For you geeks out there, Whifield Diffie, Martin Hellman, Ron Rivest, Adi Shamir, and David Chaum played big parts in the keynotes and panels. It was interesting to see both the public and private sectors well represented here compared to previous RSA conferences, and there was definitely more openness between the two. The paranoia level was high, with many keynotes commenting on organized cybercrime, cyberwarfare, cloud security. Janet Napolitano actually tried to recruit hackers and other security talent for DHS in Hollywood-esque fashion!

The sessions were actually quite good, with tracks in application development, law, hackers and threats, data security, policy and government, and governance, risk and compliance. One session I attended on data breaches was interesting; the speaker asked the audience to raise their hands if they had experienced a data breach, and three quarters of the room raised their hands. Data breaches are occurring, and to their credit, companies seem to be aggressively pursuing a strategy of prevention over cure.

Dark Reading article on FTP and Botnets

bho1 — Mon, 21 Dec 2009 19:58:41 +0000

I talked to Kelly Jackson Higgins from Dark Reading for an article she was working on. She’s been covering IT for a number of years, and her latest article discusses one aspect of a growing threat — the dangers of malicious software capturing FTP credentials and using them to hack into legitimate web sites. Because FTP is prevalent for updating web sites, having the credentials gives hackers the opportunity to inject their own code into web pages unbeknownst to the site owner. These infected pages may redirect a visitor in a phishing scam, collect user credentials on login pages, or spread the malware or bot to increase the scope of infection. There are a number of other vulnerabilities in FTP that makes it hard to justify as a viable file transfer solution, and this is just one more nail in the FTP coffin.