#789 w3af crashes when sending traffic through WebScarab proxy

[phoortis]

Notes:
- System is running on FC-13 2.6.33.3-85.fc13.i686.PAE
- Using w3af 1.1
- Using OWASP WebScarab - version 20070504-1631
- WebScarab has been configured with a listener on 127.0.0.1:8008
- The w3af http settings were configured to use an "Outgoing Proxy" at 127.0.0.1:8008. Everything else in the http Config tab was left unchanged.
- The target was a simple https://site
- I only enabled the discovery: allowedMethods plugin in order to verify my set-up
- I've verified that the WebScarab listener routes traffic correctly by pointing Firefox 3.6.7 at it and browsing to the target site manually
- A scrubbed trace back file has been attached.

[phoortis]

[phoortis]

fysa

I've been working to establish a functioning baseline wherein w3af will get along with the proxy.

I was able to push w3af traffic to and from the proxy using the following configuration wherein the w3af tool, the proxy, and the webserver are all running on the same box.

- target: http://localhost:80 (this is nothing more than the Apache test page)
- webscarab proxy is listening on 127.0.0.1:8008
- w3af is configured with proxyPort 8008 and proxyAddress 127.0.0.1
- w3af is configured to use the discovery: allowedMethods plugin **only**

I can confirm that the scan is being successfully pushed through the proxy. It completes with no errors.

Now that I know what it should look like, however remedial it may be ;), I can compare the data to a more reasonable configuration.

[phoortis]

Early indications are that I've solved my own problem. Details are below:

End Goal: Enable w3af to scan an application that requires certificate based authentication.
----------------------------
Trial Configuration 1: <<unsuccessful>>
# The w3af tool and webscarab proxy were configured to run on the same server
# The target web application ran on a second server by itself
# OWASP Webscarab was configured to listen on 127.0.0.1:8008 with *no* "base URL".
# The w3af tool was configured to run a *very simple* scan to confirm that all 3 servers were talking.
## Enabled plugins>>discovery>>allowedMethods
## set proxyPort 8008 and proxyAddress 127.0.0.1 in http-settings
## set target to point at https://fqdn (The target web application)
## started scan

The scan produced the error set originally attached in this report.
----------------------------
Trial Configuration 2: <<successful>>
# The w3af tool, webscarab, and the target web application were all configured to run on separate servers.
# Note: **Be sure** to edit the /etc/hosts file on the machine running w3af so that the fqdn for the target application actually points to the IP address where the WebScarab proxy is listening. w3af *will* pull the IP from the locals hosts file.
# WebScarab was configured with the following proxy settings for the listener:
## Address: x.x.x.133 (This is the eth0 IP for the machine running WebScarab)
## Port: 443
## Base URL: https://fqdn (for the target web application)
# Webscarab was also configured to use a client certificate by following the menu options in tools>certificates
## Note: You need to enable the fully functional interface to see this option. This is available under >tools
## Note: I used a certificate in ".p12" format
## Note: I made sure to "activate" the keystore once it was loaded. The webscarab docs actually have a "how to". You will have to re-enter the keystore password.
## Note: I needed to run Webscarab as root in order to configure the listener for 443
## Note: I needed to explicitly open up 443 on my firewall (/etc/sysconfig/iptables)
#w3af was configured with the following options
## Enabled plugins>>discovery>>allowedMethods
## Set target to https://fqdn (The target web application)
## **Do not** configure a proxyPort or proxyAddress in http-settings
## started scan
## Note: I ran w3af as root. I'm not sure if this was required.

The scan was successful with no errors. I now plan to fatten the scan beyond this very simple discovery. I'm still not sure why w3af did not like the first configuration with the "upstream" proxy. I will continue to research this issue. Hope this helps someone. It was fun figuring it out ;)

[Andres Riancho]

Migrated to https://sourceforge.net/apps/trac/w3af/ticket/160202