Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
Re: [Spike] SPIKE questions
Date: Thu Sep 25 2003 - 11:50:51 CDT
Well, that message is placed in the HTTP header that SPIKE Proxy sends
back. So if the server for some reason does not send a header or does
soemthing else crazy, you'll see that message.
It does sometimes (I can't remember if it ALWAYS does) save those requests
that cause errors in the "recent requests" log. Another way to figure out
is to look at what variable it was fuzzing in the log window. Somewhere
below that will be a little message saying "starting fuzz on...." or
I usually just go back to the page and do some manaual analysis. That's
the only way you can really tell (with any web-app-sec tool) whether your
tool is generating a false positive or not.
> Pardon my ignorance .. I usually see development questions from this
> forum so please excuse my 10,000 ft perspective. I am learning about web
> application security (and some development). I found SPIKEProxy and it
> seems like the ideal tool to use in analyzing the traffic and see what's
> going on in the background but I have a couple of questions about
> performance. I am using the 1.4.8 version of SPIKE.
> First, I frequently get this error back from SPIKE when proxying.
> Considering the error says that "I should never see this", it strikes me
> as odd that I see it in just about every response. What event causes
> SPIKE to produce this error?
> BUGBUG: You should never see this. Try hitting shift-reload.
> Content-Length: 1419 HTTP/1.1 200 OK Date: Thu, 25 Sep 2003 14:49:36 GMT
> Server: Apache/1.3.27 (Unix) mod_ssl/2.8.14 OpenSSL/0.9.7b Connection:
> close Content-Type: text/html; charset=us-ascii
> Second, when using argscan to test form fields, I watch the activity
> window at the bottom and notice that it logs test inquiries that are
> suspected to cause unexpected application behavior (i.e. Log: [Wed Sep
> 24 23:51:46 2003] : Possible injection vuln with (sqlattempt2) via 500).
>>From what I understand, unless I happen to be sitting right there to
> capture the request and response in raw traffic or am redirecting the
> entirety of the data exchange to a file, there is no way to see what
> SPIKE sent to cause this particular, suspected injection vulnerability.
> The SPIKE user interface doesnt appear to provide a reference back to
> that particular data exchange, and the log file generated for that event
> is binary. What am I missing?
> Thanks - AS
> Spike mailing list
Spike mailing list