If you are using Windows, chances are you find yourself remoting into one server or another on a regular basis to start and stop services or to take a gander at the event logs to figure out why the box mysteriously rebooted the other day at 2 am. You may not realize it, but you can access anything in the Computer Management console for your servers without ever remoting into them. This includes, users/groups, IIS, SQL Server, and device manager.
I am not just a programmer, but to some extent a sys admin. Because of that responsibility (and the fact I have had servers compromised before) I am always interested in security. I think to stop crackers; you've got to think like them. When was the last time you tried to hack into your own server? If you don't know what your vulnerabilities are, how can you close them?
If you are using MS SQL Server and ever want to just obliterate your transaction log, you can use the following SQL (where your database name is "foo"):
2 DBCC SHRINKFILE(foo_log,2)
Don't ever do this to a database you care about like, say, production. I wanted this because I am screwing around creating rainbow tables of SHA-1 hashes. The Cartesian product of joining a table to itself on 1=1 is very handy for producing all possible combinations of a set of characters. Inserting a few million records can put a lot of crap in your transaction log though.
It has been mentioned in several places that MySQL 5.0.1 has a NO_BACKSLASH_ESCAPES mode it can be run in to prevent backslashes from being an escape character. Thanks to Azadi Saryev for pointing it out on my blog and Mark Krugers as well. Jake Munson even posted instructions for applying the setting to your SQL server at startup. For the record, you can also use this setting on a specific data source.
Well, after a brief hiatus, the SQL Injection attacks have reconvened with a small change. They have modified the capitalization of a couple words in the URL. "DECLARE" has become "DeCLARE", and "EXEC" has become "ExEC". This is obviously to get around people who employed case-sensitive filtering mechanisms.
So as the SQL injection attacks have rained down on my server for the past few days, my logs have been steadily filling up with data about the requests. Frankly, the data probably can't be trusted, it's all totally un-scientific, and doesn't really lead me any closer to the people responsible for the attacks. Regardless, I think it's pretty interesting. I've compiled some graphs and stats here.
I love infinite loops. They're sort of the black hole of programming. No one really knows what you code does when it reaches the last iteration of an infinite loop, but I speculate it has something to do with String Theory and unbounded time and space increasing proportionately to the rate of dense matter being compressed by gravitational forces so strong even light can't escape. Well, that's what I came up with off the top of my head anyway. Speaking of infinite loops, I found one happening on my server today.
So, I assume you've heard the latest buzz about DNS Cache Poisoning and the subsequently released patches. It's rather interesting, and a bit unnerving that the "patch" for now simply makes the exploit harder to pull off-- not impossible. I guess that's basically because the patch simply makes name server requests more randomized. Anything more would require an overhaul to the DNS protocol itself.
I generally don't care to write about topics that have already had the stuffing blogged out of them. However, I've still seen some of these questions floating around and I figure it never hurts to have more than one place on the 'net talking about it. The two things I wanted to cover real quick are how cfqueryparam may (or may not) enhance the performance of your queries. Also, when does criteria in a query NOT need a cfqueryparam.