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.

::

Working in the information security field it’s frequently handy to be able to browse the web in different configurations. Sometimes you want to be able to see and interact with our traffic we speak with a server, sometimes you want to hide where we’re coming from on the other end, and other times we need to bypass a filter that’s keeping us from browsing.

Here are three basic configurations that achieve these objectives. I personally use Google Chrome and the Proxy Switchy extension to handle my various proxies.

1. Your Local Intercepting Proxy : Listening on port 8080 you use this to browse through Burp for standard visibility and/or HTTP modification purposes. Just set Proxy Switchy up with a new connection, all protocols, with a destination of localhost:8080. Start up your proxy and make sure it’s listening on the same port and you’re ready to go. Note: any proxy works for this; I prefer Burp on my desktop of choice, which is OS X.

1. Using Tor : You use this option to browse anonymously or to appear as another IP address to the site you’re visiting. First, install Tor , start it, and then create another entry in Proxy Switchy and select SOCKS as the proxy type (Version 5) for the port that is listening. You can use netstat or lsof -i | grep -i tor to ensure you’ve got the right port. Then select that option from Proxy Switchy and browse. Do a Google search for ‘ip‘ and notice it’s not your original anymore.

1. An SSH Tunnel : It’s useful to have this set up so that you can get around filters that block browsing over common ports. This way, if you’re able to SSH out over any port from the current network, you’ll be able to use the web as well. To configure this you need to have access to an SSH server on the Internet. Then, configure your client to dynamically connect to it while listening on a local port.
   
   On OS X or Linux, ssh -D8081 user@host. In PuTTY, go to the tunnels section and create a new tunnel with the port number and the dynamic option set, and then another with the same port number, the local option set, and your destination host and port, like so: host.com:port. Save your PuTTY session, connect to it, then switch to that proxy selection in your browser and browse through away. Check your IP again and notice you’re coming from your SSH box now¹.

I configure these browsing options immediately upon setting up any new system. Consider adding them to your basic build as well, as they allow you increased flexibility and functionality in a number of situations.

If you have any similar tips, do let me know. I’d love to hear about them.

::

Notes

¹ Be sure you have permission to bypass access controls before doing this.

I’ve always hated the “THING is dead. Long live the THING” cliché, but I’m going to use it here for CAPTCHA.

CAPTCHA raises the cost of attacking something, which improves its security. It’s that simple. The question is simply how much you raised the cost vs. the dedication and resources of the attacker.

For a random, uninteresting blog, by using a good CAPTCHA you’ve probably raised the cost of attacking it beyond what most attackers will pay. For something valuable, however, like attacking a virtual economy, or gaining access to email accounts that can be used for spam, you probably haven’t.

Using services like Mechanical Turk, which pay people to solve CAPTCHAs, this line of defense is trivially broken.

It’s important to understand that this doesn’t mean that CAPTCHAs are “lame” or “good”. Those are objective terms being used in a subjective context, i.e. one in which we’re talking about how interested and resourced an attacker is vs. how valuable a target is.

Remember to evaluate all your security controls in this way.

::

Resources

¹ http://aws.amazon.com/mturk/
² DeCaptcher.com

Michael Smith, @rybolov DDoS from Adrian Crenshaw on Vimeo.

My Internet bud @rybolov doing a DDoS talk. ::