To the audience I saw that the only information they have is the url to attack ``` http://localhost:4567 ``` and eventually a valid username.
### Prerequisite
This assumption is valid for a pentest you deliver to your customer; to be more
effective you'll be given of a regular user.
In case you don't have it, you can eventually register a new one on the
website. Finally if no registration is possible you have to blind bruteforce a
valid username. Good luck.
### First goal is to leverage the attack surface and to understand the underlying technology
We saw that it's possible to fingerprint a web application technology seeing
how the answer you get back requesting a web page, let's say the website root.
To gather all the information you can, I wrote the [gengiscan gem](https://github.com/thesp0nge/gengiscan).
Running gengiscan specifying the target here it is the result:

$ gengiscan http://localhost:4567

So our target is a ruby written web application powered by WEBrick server.
We will get further information using the robots.txt file if available. I wrote
the [codesake_links gem](https://github.com/codesake/codesake_links) you can
use either to fetch a robots.txt looking for open urls and to bruteforce the
target with a given dictionary.

Using the robots.txt, it seems developers forget to place proper redirection on
the ``` /backend ``` url. This can be interesting in a second scanning step to
try to guess backend users weak passwords.
We will also use a url dictionary to find some other urls to use.

As first step, we had that
* technology used is ruby and we have also the application server vendor
version
* we found /backend and /users links with just a couple of HTTP requests.
### Second goal is to find some regular users using user enumeration attack
Our web application [is vulnerable to user enumeration](http://armoredcode.com/blog/tales-from-a-login-page-intro/) since
it gaves two different error messages if the username is valid but the password
is not and in case both data are wrong.
I wrote a quick script available on the broken web application repository,
called ``` http_login_bruteforcer.rb ```. Check it out for futher details.
I used a regular username, tom as a canary and a dictionary of usernames you
can find everywhere in Internet.

### Third goal is to exploit reflected cross site scripting in login and in hello pages
In hello page we noticed the name parameter you have in querystring is
reflected on resulting HTML. The same happens in the /login page with POST
parameters.
We will use [cross gem](https://github.com/thesp0nge/cross) to test for
reflected XSS.