WebGyver Revisited

Validate Strong Password

Posted by admin on July 25, 2008  |  No Comments

If you ever had to code a user authentication system, you probably know how much fun it can be to write your own strong password validation. Luckily, Charles Forsyth has developed a regular expression (and published it at Regular Expression Library) that will validate a strong password.

The regular expression works for passwords that:

• are at least 15 characters long
• contain at least one (1) numerical digit
• contain at least one lowercase character
• contain at least one special character (such as !, @, #, %, etc.)

Strong passwords to be validated may not contain any whitespace, and they cannot contain the strings pass, word or password.

SQL Injection Detection Tool: Scrawlr

Posted by admin on July 9, 2008  |  No Comments

Proactive SQL Injection combatants can download Scrawlr (for free) from HP’s web site. With Scrawlr, short for SQL Injector and Crawler, you can crawl a web site, analyze the parameters of each web page and check for potential SQL injection.

According to HP’s Erik Peterson, “Scrawlr is lightning fast and uses our intelligent engine technology to dynamically craft SQL Injection attacks on the fly. It can even provide proof positive results by displaying the type of backend database in use and a list of available table names. There is no denying you have SQL Injection when I can show you table names!”

Some of the things that Scrawlr can do include:

• Identify verbose SQL injection vulnerabilities in URL parameters
• Can be configured to use a proxy to access the web site
• Identify the type of SQL Server in use
• Extract table names (verbose only) to guarantee no false positives

As with most free things, there are some limitations as to what Scrawlr will and can do (obviously, HP would like to sell its professional-strength SQL Injection tools as well):

• Scawlr will only crawl up to 1,500 pages
• Scawlr will not support web sites that require user authentication (user name & password)
• Scrawlr cannot retrieve database contents
• Scrawlr does not test forms (POST parameters) for SQL Injection
• Scrawlr does neither parse Flash nor JavaScript

If you’re not put off by those limitations, give Scrawlr a try. Because Scrawlr is free, it is not a supported product. However, there’s a Scrawlr forum, and HP encourages us to go there to post questions about the product.

Just in case you were wondering (as I was), yes, HP offers professional SQL Injection and Web Security tools as well. If you’re interested, log on to their web site (or GoogleO and look for DevInspect, QAInspect or WebInspect. All those tools, according to HP, “find SQL Injection and countless other security vulnerabilities. DevInspect can even inspect your source code for SQL Injection as well and guide developers through the process of fixing their code.”

SQL Injection on the Rise in 2008

Posted by admin on June 23, 2008  |  No Comments

A relatively new trend in SQL injection started developing late last year: Numerous web sites were defaced by including malicious HTML <script> tags in text that was stored in SQL databases — and that text was/is used to generate web pages dynamically.

According to Microsoft’s Security Vulnerability Research & Defense web site, such “attacks began to accelerate in the first quarter of 2008 and are continuing to affect vulnerable web applications.”

What surprised me most, however, was that Microsoft  listed the following three commonalities among the web sites that were especially prone to this kind of SQL injection:

1. The web sites use Classic ASP code
2. The back-end is powered by a SQL Server database
3. The web site’s code generates dynamic SQL queries, using URI query strings

Wow! Why was I surprised? Well, for the better part of the last four years or so, I’ve been painstakingly upgrading a legacy web application, running on Classic ASP (but also some C#.NET). Those upgrades included, among a ton of other security-related issues, the conversion of all in-line SQL queries to Stored Procedures.

During that time, I’ve also hired a third-party security company to make sure (every six (6) months) that no new vulnerabilities were added to the web application by me and my developers. Yes, it was painful at first, but it was well worth the effort.

Enter the scary part: As pointed out on the web site I’ve mentioned above, “these attacks have been accelerating through the year.” The researchers at Microsoft then point out that there are two significant factors involved in that:

1) There is a malicious tool that is in the wild that automates this. In a nutshell, the tool uses search engines to find sites that are vulnerable to SQL injection.

2) One or more malicious bots are now launching SQL injection attacks to spread the bot further. (SecureWorks discusses such an example in this article.)

What’s the solution? Since the enemy never sleeps, it looks as though web developers and database administrators won’t be able to rest on their laurels for long.

• Use Stored Procedures to send information to the database
• Verify that the most obvious malicious user input gets caught before it gets passed to any Stored Procedures
• Review the server logs for suspicious URI query strings
• If you find or suspect any exploits, inspect the various database tables that could have infected data
• Periodically review additional information about SQL Injection for your specific development environment

That’s all for now. If anyone has specific tips to combat this kind of web application threat, please lte me know.