[OWASP-WEBSCARAB] Call for testers - NTLM
lists at dawes.za.net
Wed Jan 4 10:22:56 EST 2006
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:
* NTLM (via jcifs)
* Negotiate (basically NTLM. There is no support for Kerberos at this time)
Please download it from
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
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
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.
More information about the Owasp-webscarab