A lesser-known attack called directory traversal is the single most commonly used technique in real-world web application attacks. Directory traversal cropped up in 37 per cent of attacks, almost the same as cross-site scripting (36 per cent), and a fair bit ahead of SQL injection (23 per cent). Remote file inclusion figured …
"Formerly little-known method now tops rankings"
Since when has directory traversal been little-known ?... perhaps the folk at Imperva haven't noticed it much but surely anyone else with even a cursory interest in security knows all about it - perhaps they might want to subscribe to SANS for a while ?
I work as a lawyer
admittedly a geeky lawyer, and *I've* known of directory traversal for years, so I'm amazed that it could be considered "little-known"...
(Heck, anyone (particularly lawyers) familiar with the prosecution of Daniel Cuthbert in 2005 under the Computer Misuse Act 1990 would be aware of it, too...)
There have been weekly, sometimes daily directory traversal attacks against my web server since it went live almost two years ago.
"A lesser-known attack called directory traversal is the single most commonly used technique in real-world web application attacks."
Does this statement not seem a little contradictory?
Perhaps it is webmasters that know little of this attack vector, because hackers are certainly aware of it. Perhaps script kiddies are too, it's hard to say for sure as running pre-made scripts requires no knowledge of what those scripts actually do.
When a request for a file/directory is made, build a full path to the file/directory, and normalize all characters. Make sure the document root is fully qualified, normalised and that the string length of this path is known. The start of any fully qualified path of any request should match the string and the string length of the document root. Any request that doesn't meet this criteria should be dropped.
Well, that list reads like a "security 101" checklist.
Seriously, directory traversal (i.e. not bothering to sanitise inputs, chroot folders - either via the calling app or via the OS -, etc.) and SQL injection (not bothering to sanitise inputs, PUTTING FECKING SQL STATEMENTS IN DATA YOU EXPECT TO RECEIVE AND ACT UPON!) - those are the most ridiculously stupid things to have yourself vulnerable too.
Follow the example of Bobby Tables. Sanitise your inputs, and never trust data you're given externally EVEN BY YOUR OWN CODE, and all these "problems" go away.
"Seriously, directory traversal (i.e. not bothering to sanitise inputs, chroot folders - either via the calling app or via the OS -, etc.) and SQL injection (not bothering to sanitise inputs, PUTTING FECKING SQL STATEMENTS IN DATA YOU EXPECT TO RECEIVE AND ACT UPON!) - those are the most ridiculously stupid things to have yourself vulnerable too."
Wise words. And yet despite the basic *simplicity* of the advice people *still* keep f**king it up.
I could never understand it, from the second I first heard about people being attacked via remote SQL injection. It's like having a DOS command tagged onto your URL. If you wouldn't allow:
then you shouldn't bloody allow SQL to creep into the URL, POST data, or anything else you intend to act upon.
You want to execute SQL statements based on an input? Okay, make up a language/translation that takes input from your web user and produces a set of SQL stanzas from it. Have external apps send ONLY that language. Have your server translate the language into a set of static PRE-FORMED SQL strings that can never change. Your PHP scripts should not have a single word of SQL in them.
You can now do simple things like: join every single translated SQL stanza in every possible combination and see if it's possible to actually get stuff out of the database that you shouldn't (and this is ASSUMING your SQL is so damn open that any web user can do things like query other tables at all). If you don't want web-users to be able to delete your tables, don't have a translation for it. It is then IMPOSSIBLE for them to do so, because they will never give you anything that corresponds to SQL that you're executing that contains a DROP TABLE statement. It's not in your "language's" vocabulary to even express the idea and you're NEVER interpreting the users input as SQL.
Also, if you delimit all the individual translated stanzas, then there is NO way to produce valid ones that do anything different by concatenating them in strange orders. You can literally fuzz-test those statements on their own and you should never expose anything other than what you intend.
Seriously people, if you don't get this, you shouldn't be managing fecking databases in the first place (the operative word being DATA, as in subject to the Data Protection Act).
Correct me if I'm wrong, but would it be right to suggest that a directory traversal attack is generally used where a script/file exists on a server but you've obscured it's presence by not offering a link to it whilst at the same time not offering up any additional protection against serving up that file/script? i.e. site admin scripts, system/running process info scripts etc. Does htaccess cover this sort of thing?
You got me there!
"A lesser-known attack called directory traversal"
Hahahahaa hehehehehehehe. Lesser known, more like as old as the hills. :P
Gawd/ess. Kids these days.
I need a drink ... and it's only half past three. In the morning.
Looking at the logs for one of my sites, I'd say scripts searching for a phpmyadmin setup script is about 80% of it, almost all the rest is looking for other PHP applications (either because they are SLQ injection vulnerable or because they won't have been configured yet, and 0% is directory traversal.
They want their directory traversal exploits back.
- Analysis iPhone 6: The final straw for Android makers eaten alive by the data parasite?
- First Crack Man buys iPHONE 6 and DROPS IT to SMASH on PURPOSE
- First Fondle Reg journo battles Sydney iPHONE queue, FONDLES BIG 'UN
- TOR users become FBI's No.1 hacking target after legal power grab
- Vid Reg bloke zips through an iPHONE 6 queue from ZERO to 60 SECONDS