Website Bot Attack Basics - Not
There’s a rather unfortunate article at webability talking about web bots and how they attack computers. The article is pretty confusing for any actual security person because what they are defining as bots are really scanners or worms. It actually gets much more unfortunate as you actually read the paper and supporting material.
If you follow the link they provide for mitigation techniques you end up on this page which is almost completely unhelpful for anyone actually looking to protect themselves from these forms of attacks. First of all it mentions SQL injection and says you need to filter out back and forward slashes and the star operator. That won’t at all protect against SQL injection and I’m not exactly sure where they got that information. It can prevent some certain vectors but it’s definitely not a panacea.
Then they say to prevent code execution you should sanitize user input and don’t use shell commands. That’s also not much of a mitigating factor if you don’t know what to santitize against. Also it doesn’t mention the actual configuration changes that really could help in lots of situations around PHP remote includes. Eesh!
Then come my two favorites. For format string injection and XSS you are simply to “Edit the source code so that the input is properly verified.” and “Edit code to avoid XSS attacks.” That’s like me saying, “To prevent accidents, make sure you avoid collisions.” How is that helping anyone?
I think part of the problem with lots of these types of articles is that developers who know nothing about any of these attacks read these things and either get a small peice of information which is entirely wrong or they get nothing out of it at all. It’s pretty painful. I’ll give the author credit for adding in a source for their findings which is an article by Sumit Siddharth and Pratiksha Doshi around five common attacks against web application security. The problem is that the article itself doesn’t really go into any depth around the mitigation factors or really even most of the attack vectors themselves. It’s really more of an editorial peice for people who have never heard of them before - which again, is not really helping anyone actually mitigate these risks.
I’m not saying don’t write about security, really, that’s not my intention, I’m saying stick to what you can actually inform people about. One of the reasons I don’t write about XSS mitigation very much is because it’s a terribly complex issue, and it’s constantly evolving at the same rate as the vectors themselves. To make a blanket statement that I’ve heard dozens of times in homebrew advisories like, “To protect against XSS remove angle brackets.” and other inane or completely mis-informed mitigation techniques is to hurt anyone who reads the article who isn’t already well informed. Clearly this isn’t the author’s target audience anyway, given the name of the original article.
August 26th, 2006 at 4:17 am
Have you ever considered writing an article on this sort of thing, and posting it on the forums, that way you can write about things u do know, and shows us all how much you do know.
August 26th, 2006 at 10:01 am
Matt, I’m not sure if you’re being facetious or not, but I’ve posted dozens of times about forms of mitigation techniques. There is no silver bullet though, which is the point of this post - acting as if one line of text will do the trick is a sure fire way to open yourself to exploitation.
Part of the problem is that for almost all the mitigation techniques there are ways around them. I’ve found more ways to break things than ways to fix things, which is part of the problem. Mitigation techniques only mitigate, they don’t solve. Right now the Internet is pretty broken in terms of security. With every new exploit we uncover (DNS pinning, Flash header spoofing, RFC1918 address javascript port scanning, US-ASCII encoding, variable width encoding) it gets exponentially harder to just flat out fix.
The point of my blog is to share some of the things I think about, not to give an instructional course on web application security. That would be tedious to write and boring to read, because what I naturally come up with is often tangential and out of order. When I see something interesting I investigate it for a few days and post what I’ve found. If people like it, they persue it, if not, it gets dropped. These opinions are mine and mine alone, take it with a grain of salt. I’ve got tons of experience in application and network security, so I’ve got a more informed opinion than most people, but it’s certainly not perfect, and I’ll be the first to admit that.
Also keep in mind that I don’t work in security anymore. I’m doing something completely different now, and security for me is a hobby only - I don’t get paid to do this. So I’m just about as unbiased as it gets. I don’t have any affiliations with any security company or application development company. I’m giving you information as I find it, without much of a filter. The only things I do filter are things people ask me to keep to myself (because they are working on something to be released later) which I do out of professional courtesy. I also cannot disclose certain things as I am under binding NDAs from previous companies for and pro-bono consulting engagements where someone needs a helping hand to vett an idea.
If you want a biased opinion there are lots of corporate security blogs out there with polished release cycles. I recommend a lot of them actually. But anything innovative will go through multiple rounds of scrutiny and take months to find the light of day if it’s anything they are developing. If people want insight into what I’m working on all they need to do is ask. And to save you the trouble of asking, I am not working on mitigation techniques. I am working on new vectors. I may switch modes in the future, but for now, I’m having a lot of fun finding holes.
September 1st, 2006 at 8:24 am
I don’t think the article was meant to do more than just attempt to educate the general public about bot attacks, and trying to slant it more towards Web applications than networks. I read the Baseline article, which is a really in-depth article on network attacks, and it looks like the author was trying to let people know that Web applications, for the unsuspecting, can lead to network attacks.
And as you point out, the title of the article points to a more general audience than a specific network-security audience. Network security people should already know this information.
September 1st, 2006 at 8:38 am
Which baseline article are you talking about? The one at http://www.webability.com/website_bot_attack_basics.html or something else?
If that’s what you’re referring to, I’d really be surprised if you actually thought it was “really in-depth”.
And this wasn’t written for network security people anyway, it was written for application security people, as every single attack mentioned was application security related, not network related - excepting of course the fact that you can block IPs at the network or something else innane (which doesn’t fix the broken door, it just moves the door to the left slightly so the attacker needs to switch IPs).
September 20th, 2006 at 10:43 am
Here is the Baseline article:
http://www.baselinemag.com/article2/0,1540,1946694,00.asp
September 20th, 2006 at 10:51 am
Yes, I would agree, that is a pretty in depth article, but it actually deals with real mitigation techniques: http://www.baselinemag.com/article2/0,1540,1946413,00.asp
Unlike the ones mentioned in the webability article I am talking about, which mentions only web application issues and doesn’t actually realy go into how to mitigate them at any level. The general public doesn’t even know what cross site scripting is, which is why I don’t think that it’s targeted for the general audience, and normally you don’t discuss mitigation techniques on server technology to the layman. You discuss turning off JavaScript or not clicking on links as the baseline article goes into to some degree.