Image courtesy: xkcd.com

See how simple it can be? Now try other examples on your application under test

Over the weekend I had a need to hack into a site to make some changes and do some testing. (It was all on the up and up, the client was aware.) At one point, I ran into a spot where I needed to work with the MD5 secure hash algorithm. I found the informaiton, resources, and the tool provided by JavaScript MD5 to be very helpful in figuring out what I needed to do.

Found a new free fuzzing tool by Microsoft called MiniFuzz. From the site:

MiniFuzz is a very simple fuzzer designed to ease adoption of fuzz testing by non-security people who are unfamiliar with file fuzzing tools or have never used them in their current software development processes.

While it's focused specifically on file-handling, it's relatively easy to get setup and use. I don't use Visual Studio, but apparently, you can also use it as a VS add-on.

I'm again stealing a tip from David Christiansen (he's on a roll lately). Checkout his post on using cross-site scripting to get out of a testing rut. From the post:

<script>alert("f")</script>

Paste it in every field.

If an alert pops up OR the field gets saved and then gets rendered without the script tags, you’ve found a cross-site scripting vulnerability.

---

As a side note, in a very funny turn of events, when I originally wrote this blog post I was rewarded with the following...

It's fairly common for applications to pass sensitive information. When testing, it's our job to make sure that sensitive information, wherever it gets passed to, is stored in a way that's (at least relatively) secured. The first thing I look for is plaintext storage of information. Some common places to look include:

• file or disk (cookies, configuration files, temp files, etc...)


• the registry


• memory


• databases


• the GUI (urls, field properties, hidden fields, etc...)


• executables (I've never reverse engineered a binary, but I know testers who do - and they find license keys, passwords, and other key pieces of information)


• or even just information going across the wire

Checking for plaintext information for the list above is trivial for everything except memory and executables - and for those you can probably setup and learn the tools in a day or two. I find I don't check those two as often, but I do check the others.