Dirbuster is a tool used to help discover content on a target website during an assessment. It does so by making a massive number of requests for directories to a given site and documenting the responses.

Here are a few options I like to set when using the tool:

• Enable the following of redirects
• Change my user-agent to a common IE or Firefox version
• Limit the requests-per-second I can send based on host
• If the site is hosted on IIS, use the lowercase word lists
• Lower the timeout period
• Avoid guessing files unless you have a lot of time or it’s a small site

Just enabling redirects will get quite far superior results.

That being said, remember that Burp supports content discovery as well, but not custom wordlists. The advantage there is that the Burp discover is…well, Burp-aware.

::

There’s been some debate in my circles recently on the topic of what type of person and background makes the best web security tester.

The issue is that web testing involves and requires a number of skills. It includes performing a staggering number of monotonous actions according to a methodology, as well as being able to use deduction and creativity to pivot off of discovered issues to find additional and more serious vulnerabilities.

Most people are good at one of these and not the other, i.e. most who can follow a methodology and not get side-tracked aren’t so great at the deep knowledge and creativity, while many who have the talent to find issues by deduction have trouble following a methodology.

So the question is simple: if you could only have one, which would you want? Do you want the non-security-guru who finishes a methodology, or a far less disciplined and focused stud with the ability to go much deeper into any given vuln?

I’ve heard both arguments over my years in webappsec. Back before I got into it full-time I heard a couple of tech veterans lambasting webappsec testing completely, saying it was, “Something for QA types — not security people.”

Being a security type I was somewhat miffed that they would think QA testers could handle such a complex and nuanced subject as security. This coming from a 10-year veteran of infosec, you understand. Naturally I was a bit defensive.

But now I’m starting to wonder how right they might have been. I’m starting to lean more in the direction of methodology completion vs. talent, which is precisely what game testers and QA types excel at. And this seems to be precisely the point that those guys were making.

I wonder where you all come down on this topic. What’s more important: completeness or depth? Discipline or talent? QA types vs. Security types for web testing?

I look forward to your thoughts.

::

Anyone who does web security testing knows that the browser is the most important tool in the arsenal. Scanners are nice and can help save time, but no technology is the equal of manually making requests to a page while passing through a good proxy.

Linkclump is a Chrome extension (you are using Chrome, right?) for selecting multiple links at one time, which then open in their own tabs.

This way you can take a page you’re testing with tons of links on it and just drag/select them to make your proxy aware of them (and/or start testing them actively).

Linkclump. Get it.

::

Dinis Cruz did a presentation at OWASP recently on why security should be invisible to developers.

His basic idea is that security is for security people and building things is for people who build things. He says that security people should stop rubbing developers’ noses in their problems and make security transparent so developers don’t need to think about it.

This is mostly a horrible idea.

The easiest way to see this is to take the concept of “building” to any other domain. Quite simply, anyone who “builds” something needs to be responsible for its security. Whether it’s a skyscraper or an automobile, the excuse of “You didn’t give me secure stuff to build with so I made a death trap.” isn’t a strong defense.

It’s true that there are different types of people who “build” buildings. There are those who design them and then there are those who put drywall in and nail up plywood. And perhaps the argument is that people who do basic construction shouldn’t have to know how to build a structurally sound skyscraper.

Perhaps, but someone who is responsible for building that structure is accountable for its design — including security. And that someone is most definitely a builder.

So if we’re saying regular construction people are like regular developers who don’t need to know the ins and outs of security, then I ask you who the architect is. Remember that you can’t just send a bunch of hammer and nail guys in to build a skyscraper — you need an architect to lay out an approved plan.

That architect, is held accountable for the design, and that’s the piece that we’re missing in software. It’s not right to say that developers shouldn’t have to know security; that’s false. They need to be identified as one of two types: hammer and nails guys or design guys. If they’re hammer and nails guys then they shouldn’t be allowed to code without supervision of someone with security skills. And if they’re design guys then they should be able to code securely without supervision.

But the one thing that’s completely out of the question is the notion of nobody doing the building (of whatever) having any clue about security. It’s not true anywhere else, and it shouldn’t be true for software either. Security is part of quality. If you build an insecure program you’ve built a crappy program. Good builders don’t build crappy programs.

Security is now part of the process, and it will only become more so as time goes on. If you’re asking for it to be easier for developers to be good at understanding the security of their applications, then I agree. But if you’re saying make it easy so that they don’t have to understand it…definitely not.

Developers don’t get a pass on security. It’s just like building anything else that is used by others and has any sort of security/safety implications. The responsibility resides with the creator of the object, not with those who come by to audit him. ::

I’ve just created a new RSS feed for application security news using Yahoo! Pipes. It’s located at:

http://pipes.yahoo.com/danielmiessler/appsecnews

It has about 10 sources, and should provide a solid feed of information from the appsec community. Any comments on additional feeds that should be included are welcome. ::

I believe too many people take the wrong approach to security, or “hacking”. Most who seek this ability clamor for answers to questions like, “How can I hack SQL?” “How can I hack Linux?” “How can I hack web applications?” There’s a really simple answer. Learn SQL. Learn Linux. Learn to build web applications. What people call “hacking” actually reduces perfectly into two simple things:

1. Deep understanding of a technology
2. Making it do something it’s not supposed to do

Once you combine a deep understanding of something with curiosity, all sorts of ways of abusing said system are presented to you. This requires talent, skill, and practice — don’t misunderstand — and there are many hardcore developers who understand their technology extremely well but couldn’t hack a vegetable cart. Why? — because they lack curiosity and/or the attacker mindset, so they never get to step 2.

In truth, I’d actually say that developing on, or mastering, a technology is not only the best method to becoming good at security, it’s actually the only method. Anything less is a 0 in a world where 1 is the standard. If you don’t know SQL then you don’t know SQL Injection. If you don’t know operating systems then you can’t break operating systems. And if you can’t build a web application then you aren’t really doing WebAppSec.

You can use blunt tools to take chunks out of these subjects (tutorials, automated scanners, etc.), but to truly be good at breaking something you must know how it works. Anything less is hamfisting.

Don’t be a hamfister. ::