[OWASP-WEBSCARAB] Call for testers - NTLM

[Rogan Dawes]

Hi folks,

After much procrastination, I have finally implemented an authentication 
framework for WebScarab. WebScarab can now communicate with webservers 
AND proxies that use the following authentication methods:

* Basic
* NTLM (via jcifs)
* Negotiate (basically NTLM. There is no support for Kerberos at this time)

Please download it from 
<http://dawes.za.net/rogan/webscarab/webscarab-installer-20060104-1611.jar> 
or 
<http://dawes.za.net/rogan/webscarab/webscarab-selfcontained-20060104-1611.jar>, 
and let me know how it works for you? Based on feedback received, I'll 
make a new release.

For those who want technical details, this is what changed:

I modified URLFetcher (the part that actually communicates with the 
server/proxy) to handle authentication automatically. It works in the 
following way:

If URLFetcher gets a 401 or 407 response, it checks to see if WebScarab 
has credentials that match the host and realm (for Basic auth), or just 
the host (for NTLM or Negotiate). If WebScarab does not have any 
credentials at that time, it will prompt the user to enter the 
credentials. It then constructs an appropriate (Proxy-)Authorization 
header, and sends it off automatically, without returning anything to 
the user/browser, until either it gets a non-401/407 response, the 
Authorization header was the same as a previous request, or it has done 
3 unsuccessful round trips (basically a fail safe).

In this way, the various plugins can create requests without having to 
worry about authentication, and the framework will take care of that for 
you.

If you look at the request in the Summary, you will see that the 
archived request contains the credentials that were used to retrieve the 
response. These may be in standard "Basic BASE64(username:password)" 
form, OR, it could be a non-standard "NTLM BASE64(domain\user:password)" 
or "Negotiate BASE64(domain\username:password)" form.

This links the credentials with the request, so you can check how you 
managed to retrieve that particular page, at a later date. More 
importantly, if you want to replay that request, it will use those same 
credentials, regardless of whether you had changed the credentials via 
the Tools->Credentials window.

What this means is that you can hand-craft an appropriate 
(Proxy-)Authorization header (in e.g. Manual Request), and it will be 
used in preference to the stored credentials.

I apologise if this explanation is a bit rambling, please mail the list 
if I have left something out, or if anything is unclear.

Regards,

Rogan