AnthonyPegram.com // music, games, programming, life
Search Updates
Page: 1 2 3 4 5 6 7 8 ... 44
 
The Weather Outside Is Frightful
December 18, 2009

It's snowing right now, and the Weather Channel is calling for 8-12 inches of the stuff by tomorrow. The kid in me would love to see it happen, regardless of the fact that it can no longer get me out of school. The cynic in me will believe it when I see it.

Song O The Day: Jingle Bell Rock, Thousand Foot Krutch.



 
Things do not need to be so worrisome
December 17, 2009

At work over the past few days, issues regarding SQL Injection vulnerabilities have come across my desk. The short story about a website being open to SQL Injections is that a malicious user could attack your database and either gain access to sensitive information, modify it, or even delete it entirely. The short, short story on SQL Injections is that they are very bad.

Let me give an example. Let's say you have a search form on your site, and you get a URL like the following:

www.justanexampleurlhere.com/search.aspx?term=Red

With such a URL, you would expect the code to pass the term "Red" to whatever algorithm that hits the database and returns the search results. A malicious user could try to alter the URL and do the following:

www.justanexampleurlhere.com/search.aspx?term=Red';delete from customers--

If this site is open to SQL Injection attack, that site may have very well just lost all of its customer data. Scary stuff, right?

Anyway, these issues came to me. I've had to fix similar issues before, so I dug into the code to see what was happening. Invariably, the case is that another company's developer did not properly deal with rogue or unexpected data input. I saw code like the following:

string input = Request.QueryString["id"];
string validatedInput = input.Replace("'""''").Replace(";""").Replace("--""");
// go to database with validatedInput

The above code works. In fact, in a SQL Server environment, it's borderline overkill. When you are working with string data, the real killer to look out for is an unescaped single quote. It's the single quote that is a string delimitter in the SQL Server world, so when you have one that is unescaped, you are open to hackers going to town on your database. Everything else being checked against is only dangerous in the case of the rogue single quote! Fix the single quote by escaping it (meaning, replace a single instance with two), and off you go. That's all well and good when you're dealing with string inputs. The problem is that the database does not always expect a string!

If you are dealing with a string of text, by all means, fix it up. But if the database is expecting an integer, verify you are working with an integer. Fixing a rogue string is not making your data secure when you leave an opening with something that should be an integer input. For example, let's say I fix up all strings to handle single quotes and whatever other characters I want to eliminate. I'm still open to a hacker gaining entry into the database. Assume there's a page that shows all the products of a given supplier.

www.justanexampleurlhere.com/products.aspx?Supplier=107

A hacker could modify that URL without using any "illegal" characters and get a much different result set.

www.justanexampleurlhere.com/products.aspx?Supplier=107 or 1=1

In the case above, no real harm was done to your data, the user would just see more results than otherwise intended. But what if it wasn't a simple products page but rather a login form to get entry into the backend of the website? Now the user may be able to employ similar techniques and suddenly the hacker is staring at all of your sensitive data and can do whatever he wants with it. Alter it, delete it, use it, sell it... whatever. Scary!

Fixing a string is not going to help you when you shouldn't be allowing strings anywhere near your non-string data! The code above is not going to preserve your data integrity from such an attack!

string input = Request.QueryString["id"];
int validatedInput = 0;

if (int.TryParse(input, out validatedInput))
{
    // safely go to database because input is 
    // actually what you expect it to be
}
else
{
    // never EVER go to database with this input!
}

Come on, people. SQL Injections are not overly hard to protect against, but don't fix what is completely invalid and think you are safe.


A note about single quotes: In the post, it may come across that single quotes are the devil. In actuality, that's not true at all. My post is full of them, as a matter of fact, and my post is going into a database. They're of legitimate use 99.99% of the time in any web or database interaction. It just also happens that they're the path of entry for most malicious attacks using string data because people do not properly deal with them. The point is that you cannot construct a SQL statement with a single quote in the middle of a string and achieve the expected result. As I said above, it is what is used to delimit a string. Take the following SQL statement.

Select * From Products Where ProductType = 'PC'

The single quotes around PC are what tells the database that PC should be treated as a string. If we put another single quote in the middle, making it 'P'C', the database thinks the string is 'P', and then there's data following it (C'), which (in this case) would cause a SQL error. In order to get the database to treat that middle single quote as just another part of the string, all we have to do is double it, which results in the string we submit being 'P''C', and the database will actually store or use P'C. That's all we have to do, and we have to do it anytime we think we will be working with a string that has a single quote. The basic truth of the matter is that when you're working with a database in code, you should always assume your string will have a single quote, whether it is something you created yourself or if it is based on a user input. It's simply best practice to deal with it that way. Otherwise, the best-case scenario is that we build a SQL statement that just doesn't work and potentially causes an application or a webpage to crash. Worst-case scenario is that a malicious user causes us to build a SQL statement that does work but performs activity that is not intended.

Always escape those single quotes! But the main point of the post is to always, always verify you're working with the right type of data, because strings are only one of the types you will use in a database. Don't go to the database with a fixed string when you should be going to the database with an integer, or a date, or a decimal value, etc.

Song O The Day: My Favorite Things, Family Force 5.



 
Two for Two Again
November 18, 2009

The youth group has been doing a Sunday night Bible study series for the past few weeks, and pretty much after every meeting one of the youth needs me to take him home. I've needed to drive him home the past couple of Wednesdays, as well, including tonight. Dude lives out in the middle of nowhere in Rockingham County and I usually spot one or more deer either on the way to his house but more typically on the different roads that will lead me back in the direction of Greensboro.

Anyway, tonight, I spotted two deer off to the side of the road and wouldn't you know both of them decided to run across it as I was approaching. They darted across the road and I just knew I was going to slam into one or both of them. The road was wet, I jammed on the brakes but it was basically useless as I just slid right towards where their direction was going to take them. But somehow, by the grace of God, I missed them both. I kid you not, there couldn't have been more than a car's width between the two of them as they crossed the road, but somehow my trusty Mazda Tribute half-slid, half-drove through the middle of them.

I'm telling you, Bambi and his friend nearly bit it, and I about had a new car.

There was a third deer later on, just off the road when I was barely inside Greensboro, but at least that one had the sense to stay where he was.

Song O The Day: My Hippocratic Oath, Philmont.

 
Two for Two
November 17, 2009

Duke went two-for-two against schools I attended. Last week, they beat UNCG. Tonight, they dominated UNC-Charlotte, where I attended for 3 semesters before transferring to Greensboro. That's alright with me. Duke fan first, UNCG/UNCC alumnus second.

Song O The Day: Chasm, Flyleaf.

 
Basketball Season Is Here
November 13, 2009

I'm sitting here watching Duke play my alma mater, the UNC-Greensboro Spartans, in the opening game of their season. I don't know what to expect from Duke this year, but as with the past few years, I'm not really expecting much. They'll be good, probably top 10-15 all year, and sports writers might even overrate them up into the top 5 at some point, but I'm not going to kid myself. They're thin on guards and on athleticism, so they'll be at a disadvantage again come tournament time. Oh well, I'll enjoy what I can.

In unrelated news, Flyleaf and Switchfoot each came out with new albums this week and they're both awesome. Check them out.

Song O The Day: Mess Of Me, Switchfoot.

Page: 1 2 3 4 5 6 7 8 ... 44
Updates
I'm Anthony Pegram. This site is a place where I can talk about things that interest me in music, video games, programming, and other parts of life. It's also a place where I test the latest and greatest in programming technology. Thanks for stopping by.