Review of Initial Buffer Overflow Code

[GoogleCodeExporter]

Issue URL
https://code.google.com/p/zaproxy/issues/detail?id=1297&start=300

Summary of changes
Initial Review:

Build instructions (if non standard):
This belongs in extensions/ascanrulesAlpha

Current status (Alpha/Beta/Release):Alpha

Requested Status (Alpha/Beta/Release):Alpha

Publish to Marketplace (Y/N):Y

Anything else we should know:
This is the first attempt at a buffer overflow rule and there a lot of things 
to add in the future and I hope to keep this as an ongoing thing.  I have a lot 
of methods that are set to private that might be useful as public including one 
to generate arbitrary random character strings and random odd character strings.

Original issue reported on code.google.com by msra...@gmail.com on 9 Aug 2014 at 12:02

• Merged into: #1297

Attachments:

• BufferOverflow.java

[GoogleCodeExporter]

I haven't had a chance to run it yet or play with it, but here are a few 
thoughts just reading through it.

@line 127 - This assumes a static order of attributes for input elements. i.e.: 
That type always appears before name, and that name always appears. (Also @line 
228, perhaps this is better defined as a constant?)

@line 144 logging seems to be mainly relevant to the original dev, 
"baseResponseHeaderg"?

@line 145 (and around this line) it seems confusing from a maintenance 
perspective it seems confusing to refer to a response as a request, i.e.: 
HttpResponseBody requestbody= msg.getResponseBody(); ... also around line 168

@line 182 bingo does not raise the alert at the same level as specified @line 
198 in getRisk ... why doesn't the bingo just call getRisk?

@line 214 assumes that action is always the second attribute in a form 
declaration.

General:
* I don't know if there is a ZAP coding guide or style guide. However the 
majority of code I've seen uses camel-caps for function and variable names.
* I viewed this file via web browser (not IDE), but I assume it shouldn't 
really matter. There seems to be many inconsistencies with regard to 
indentation. 
* It may be more efficient to use compiled regexes vs doing string searches 
using indexOf.
* Why limit to "text" input type? 
http://www.w3schools.com/tags/att_input_type.asp
* Instead of just searching for a particular field type (or set of field types) 
why not just look at and manipulate the parameter list?

Original comment by kingtho...@gmail.com on 10 Aug 2014 at 1:23

[GoogleCodeExporter]

Thanks for the input, I will look into those lines of code. I need to make
the text field detect more robust, but this is just the initial cut.

As to the indentation, it shows up fine in eclipse so it may be skewing
caused by the browser.

as to the comment " Why limit to "text" input type?
http://www.w3schools.com/tags/att_input_type.asp"  There will be more types
added as time goes along, but one must start someplace and string overflows
are probably more common.

as to the comment " Instead of just searching for a particular field type
(or set of field types) why not just look at and manipulate the parameter
list?"  Ive just started playing with this software package after a few
years out of the game.  How does one access the parameter list.  If there
is a better way to get access to the fields that are looking for text input
let me know, I have no pride of ownership.

Original comment by msra...@gmail.com on 10 Aug 2014 at 2:30

[GoogleCodeExporter]

Agreed on the Eclipse vs browser thing. No biggy.

Just doing text fields as an initial cut is totally fine. Just didn't want 
other stuff to be overlooked.

As for accessing parameters from an HttpMessage you can do getParamNames(), 
getFormParams(), getCookieParams(), getUrlParams(), etc. On the flip side there 
are similar set functions as well.

Keep up the great work!

Original comment by kingtho...@gmail.com on 10 Aug 2014 at 5:54

[GoogleCodeExporter]

Well, I am uploading a new version.  This is about a 70% solution to the last 
comments.  I still need to rewrite the parsing piece to find the text fields 
and the return CGI program.  Its interesting how flexible and inflexible the 
return is.    An example is the field name="return"  the name and = can have as 
many spaces in between as you need, but the "return" variable can have no 
spaces between it and the "'s  another is the <input type = blah name="return"> 
 There can be no other > characters between input type = blah and name = 
"return".  Gonna try and figure out how to get the parameters from the 
documentation and examples but may do a first cut just doing my own parse.

Original comment by msra...@gmail.com on 16 Aug 2014 at 7:42

Attachments:

• BufferOverflow.java

[GoogleCodeExporter]

(IMHO) There's one thing that should be addressed before doing any other 
changes, which is, from what class (e.g. AbstractAppParamPlugin, 
AbstarctAppPlugin, ...) should BufferOverflow extend based on what's (not) 
currently doing.

The class AbstractAppParamPlugin already provides the input vectors of the 
message (i.e. from the request, which were previously extracted with the 
Variant* classes).

When extending from AbstractAppAParamPlugin the steps done in the method 
scan(HttpMessage msg, String param, String value) are roughly:
1. testMsg = getNewMsg();
2. setParameter(testMsg, param, attackPayload);
3. sendAndReceive(testMsg);
4. Analyse testMsg's response;
5. Raise alert or go back to step 1 and use another attackPayload...

With the AbstractAppPlugin you just get a message (i.e. by calling the methods 
getNewMsg()/getBaseMsg()) which you (normally) need to analyse/process before 
performing any tests.

Based on what the class BufferOverflow is currently doing (i.e. manually 
extract the input vectors by parsing the response) it should extend from 
AbstractAppPlugin not AbstractAppParamPlugin.
Note that as is now the scanner might/will perform the same test n times, being 
n the number of input vectors extracted from the message.

My recommendation though is to remove the manual extraction of the input 
vectors and rely on the input vectors already provided by 
AbstractAppParamPlugin.

Original comment by THC...@gmail.com on 20 Aug 2014 at 6:56

[GoogleCodeExporter]

I believe that I use most of this.  Based upon the example code and sorting
through your code base.  I use the following.

msg = getNewMsg();

 sendAndReceive(msg);

I don't use the setParameter(msg, param, attackPayload) because I could not
figure out a way to use it or get access to the input vectors.  I probably
am not understanding you use this thing.  So how would I use it to get
access to the input vectors and path?

Original comment by msra...@gmail.com on 20 Aug 2014 at 12:10

[GoogleCodeExporter]

Based upon the previous input I have rewritten the code to use 
AbstractAppPlugin.  That seemed the most logical to do.  I have also rewritten 
the parser to be more generalized and look for certain types of grammar and 
keywords.  This should be ready for review and improvement. 

Original comment by msra...@gmail.com on 26 Aug 2014 at 2:03

Attachments:

• BufferOverflow.java

[GoogleCodeExporter]

Too late... anyway re comment #6, you don't need to access the input vectors 
and path, those details are already handled by the base class.

You just need to call the method setParameter(HttpMessage msg, String param, 
String value) with a large payload, send the message and then analyse the 
response, that should do it.
Have you tried that with your test case?

If it's useful to know the type of the input vectors (e.g. query component, 
POST, HTTP header, ...) you can access it by overriding the method 
AbstractAppParamPlugin#scan(HttpMessage, NameValuePair) and call the instance 
method NameValuePair#getType().

Please let me know if you have any other question on how to use the class 
AbstractAppParamPlugin (or how it works internally). The class 
AbstractAppParamPlugin seems to be a better option than AbstractAppPlugin for 
this use case.

Re comment #7, if you still want to go ahead with parsing the response to 
extract the forms (which I discourage in favour of using 
AbstractAppParamPlugin), you might be better served with Jericho HTML Parser 
[1] (bundled with ZAP by default). For an example on how to use it see the 
methods ExtensionAntiCSRF#getTokenValue(HttpMessage, String) [2] and 
ExtensionAntiCSRF#getTokensFromResponse(HttpMessage, Source) [3].

A quick comment regarding the manual composition of the request body for 
submitting the form, you might need to (or should) send all (valid) input 
fields, not only the "text" ones, to (try) trigger the overflow, otherwise the 
request might be rejected by a missing required field before any process/use of 
the overflowed/attacked field.

[1] http://jericho.htmlparser.net/
[2] 
https://code.google.com/p/zaproxy/source/browse/trunk/src/org/zaproxy/zap/extens
ion/anticsrf/ExtensionAntiCSRF.java?r=5281#218
[3] 
https://code.google.com/p/zaproxy/source/browse/trunk/src/org/zaproxy/zap/extens
ion/anticsrf/ExtensionAntiCSRF.java?r=5281#247

Original comment by THC...@gmail.com on 26 Aug 2014 at 5:59

[GoogleCodeExporter]

>composition of the request body
In the current case it should be "query component" not "request body".

Original comment by THC...@gmail.com on 26 Aug 2014 at 6:03

[GoogleCodeExporter]

I have read your comments, and have tried to use the set parameter method.
It does not seem to work and I can not find any concrete examples of how to
use it.  If I could then maybe I would.  I'll look into using the Jericho
parser but don't know if I can get it done within practical time limits.
Also as I have previously stated this is an initial cut to get something in
the repository then add improvements and other types of input.

Original comment by msra...@gmail.com on 27 Aug 2014 at 2:56

[GoogleCodeExporter]

Could you provide the code when using the setParameter method?
Which "Injectable Targets" ("Options" > "Active Scan Input Vectors") do you 
have enabled? What are the exact steps that you are doing to test it?

As an example you can check the scanner TestRemoteFileInclude, it's using the 
method setParameter [1] (it basically follows the 5 steps mentioned previously).

OK.

[1] 
https://code.google.com/p/zap-extensions/source/browse/trunk/src/org/zaproxy/zap
/extension/ascanrules/TestRemoteFileInclude.java?r=1498#205

Original comment by THC...@gmail.com on 27 Aug 2014 at 4:50

[GoogleCodeExporter]

Have you looked at 
http://zaproxy.blogspot.co.uk/2014/04/hacking-zap-4-active-scan-rules.html - 
this explains how to write active scan rules and shows AbstractAppParamPlugin 
being used.
You should not be trying to find your own input vectors, that will prevent the 
users from being able to configure them.
If you can show us the code you're trying to use then we will hopefully be able 
to correct it.

Original comment by psii...@gmail.com on 27 Aug 2014 at 5:34

[GoogleCodeExporter]

Ok,  Per a post I put on google groups

The setup

Server is a stock apachie page (testpage.html).  It calls a single CGI
script.  Before I dynamically code the string for the return, I set up a
hard code call to make sure everything works.

This is encoded as

             setParameter(returnmsg, param,
"cgi-bin/cgi-overflow?pipenum=ZAP");
            sendAndReceive(returnmsg);

When I look at the spider log I get the following was sent to the server

GET http://tpath2/cgi-bin/cgi-overflow?pipenum=ZAP HTTP/1.1

What my command sends is

GET http://tpath2/cgi-bin/cgi-overflow%3Fpipenum=ZAP HTTP/1.1

Using the responses I got from this thread I followed up with the code that
I put in the repository.  My code in a nutshell parses through a server and
finds the action

<form action="/cgi-bin/cgi-overflow" method="get">
and all of the

<input type="text" name="pipenum">
to stuff the returns with very long strings.  Next step would be to add
multi-line text, numbers, etc.  The parser finds the parts I need but, if I
form the proper return string using setParameter(msg, param, attack)
something in the abstract class mucks with the return string as noted above
and the web server can not decipher the return string properly.
setEscapedParameter does not work either.  Believe me I tried.  The whole
discussion is under the Developers Group heading of

Formin ZAP Query

I have attached the code that I uploaded for review.  To change what is in
for review to use setParameter would be a heck of a lot easier, but what am
I missing about its use?

Original comment by msra...@gmail.com on 27 Aug 2014 at 10:30

[GoogleCodeExporter]

The path/query (or whatever input vector type is being changed/formed) is 
already constructed and updated by the base class.
You just need to set the overflow payload and the base class will take care of 
the rest, for example:
HttpMessage newMsg = getNewMsg();
setParameter(newMsg, param, randomCharacterString(2100));
sendAndReceive(newMsg);
// Analyse the response...
// if (chkerrorbody.contains(checkStringBody1) && 
chkerrorheader.contains(checkStringHeader1))

Could you try that?
Note though that the scanner expects the form to be already submitted. You need 
to manually submit the form (or use the spider) before active scanning.

Original comment by THC...@gmail.com on 28 Aug 2014 at 6:35

[GoogleCodeExporter]

Ok, I tried to use again, with no joy.  What basically happens is this does not 
stuff the string as was suggested into the parpameter fields.   As a non pretty 
rewrite I used the following

String checkInputTypeString = "<input type=\"text\" name=\"";  // look for text 
fields to fill out
            String checkStringHeader1 = "Connection: close";  // Un natural close
            String checkStringBody1 = "500 Internal Server Error";  //No response
            String errorBufferOverflowMessage = "Potential Buffer Overflow.  The script closed the connection and threw a 500 Internal Server Error";
            // Always use getNewMsg() for each new request
            msg = getNewMsg();

            sendAndReceive(msg);

            int baseResponseLength = msg.getResponseBody().length();
            log.debug("BASE baseResponseLength was:" + baseResponseLength);

            HttpResponseHeader requestReturn = msg.getResponseHeader();
            String returnString = requestReturn.getHeadersAsString();
            log.debug("BASE baseResponseHeader was:" + returnString);
            HttpResponseBody responseBody= msg.getResponseBody();
            returnString = responseBody.toString();

            // This is where BASE baseResponseBody was you detect potential vulnerabilities in the response
            String checkTextField = responseBody.toString();

            //Look for and count text inputs

            log.debug("Looking for Textfield");

            if (checkForInputField(checkTextField)){// at least one text field to fill out
                //msg.getRequestHeader().getURI().setPath(cgiPath(msg));
                String returnAttack = textMessages(msg);
                log.debug("Build string was: " + textMessages(msg));
                //msg.getRequestHeader().getURI().setQuery(textMessages(msg));
                HttpMessage newMessage = getNewMsg();
                setParameter(newMessage, param, randomCharacterString(2100));
                sendAndReceive(newMessage);
                requestReturn = newMessage.getResponseHeader();
                returnString = requestReturn.getHeadersAsString();
                log.info("CGI Return Header was:" + returnString);
                responseBody= newMessage.getResponseBody();
                returnString = responseBody.toString();
                log.info("CGI Returnbody:" + returnString);
                requestReturn = newMessage.getResponseHeader();
                String chkerrorheader = requestReturn.getHeadersAsString();
                String chkerrorbody = responseBody.toString();
                log.debug("Header: "+ chkerrorheader);
                if (chkerrorbody.contains(checkStringBody1) && chkerrorheader.contains(checkStringHeader1))
                {
                    log.debug("Found Header");
                    bingo(getRisk(), Alert.MEDIUM, null, msg.getRequestHeader().getURI().getPath(), returnAttack, errorBufferOverflowMessage ,msg);
                    return;
                }
                return; 

This is the response I got on the debugging.

<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access 
/pERyaZbJNuNGMrKpXtLMMxmIohysSiERFRITATjbbrvnKtuEBQpsQrBEaAvEuDQlagijPQymJQOmbie
NHHbnadApHCJBAYCupplYXfohHRgJKUnLofwAoHIiCEIQQavvbHcaqNTqsgDXXmPGCWCCWtqPAMWpsxK
TiwBASYhBFqkWUTKIEsRgmxTRenWbrZHIjTQUMdSjeimQFWJGeWCAZPpFVZselaCsLAFnQMrcPiLDwcP
RmXcveMsNwxUUMWroPeAkKdSnHGNcPJvPuXKRDDapSPBetlmfOCegYesdRFccNJfHIatHVjqemrlOnOl
QFDudYwxNOkyaEvyvoFlKmyXrKTuIQGxwZbSeFZiEuRBqvwUCMiujSoRKiqcwxVXCCkchYIPviGkrJvq
LRhpLEpgRGVHRDmrieoqtCMxWsFxRLeERNMudmXScSRmcrhJJQKNbEFXKsmmeQspkTdrSmGjUGrQGFpR
QTaTmbKRVyKVUUrhWHTdZmgaXrwXrqQQWCfZMusGYwWyTkdCwZThOqlZnwFDGPEZYksigEAJBCjUwJTT
FKnFkwMopWHsyGPXjjqPOLaykBMHcoinerTSOCJwIoqeuWnfJiaucsvtQLPxTNtFIyGvssnQUfPwYDVZ
JWIovRpLRAnfPhYESWJubbHgqNOWVJhDxQbheBwVmXvIvDlqkprkODibRtjAfDQgLPWUoZZnkZlsVObf
jtmyjKHCffCihplmMjGPSQPkqcGIIxiyEUCWKgOXrSYnFnjIqKGBRmoADAwCjmYDkeOjUuEQRXBvsuLK
GnjfIlIpqtfFGhWakZpANRfClYLOpraEhCiLKIdQyQVHKZqFrWYLnemWsUftglDenUOwQRchtLnXjKJA
aXgyymvidQFrcLeTfTrPNGCZhduZOpLpdgYnlpUEqrlPEODiJEMkpppGUGAIFseDvCXSFWSPqdPatUTp
hAwVEHpCcZaHeORumWFmtebMWuOmkuLhmSydwAfpwBJceHXeeipSDHfnjfxXcVDHAccwtnCQEPlmaqap
iLNSxwNJiIwqJPxtcMvQBeoAKOVcSyiLPreoQRXagDdyswVxBOmwXVHWbIGbxqNWRPerPEMAgqkvBcKJ
vAvTNFFfQGRtefoPaSCxLUvBUqrwPwHmhRXIHrZsvOrCLOhjhliYuJIKkGZpLQclxThxixnwtvUqGimK
QwDaSFuXeXUkVhqZbkjtOKeREGBqmdYBgupIhhOSeDgUyjmHbiueEZHuBLoxkLrwQNHTHRtxVOSKCGin
owOHjiMguOhtrHIpCnPMcBlxBQjfupSoKiWZJJuPwpOOwumFBSHgaEijpQBhQRIQLJdWrLHcDCRusJUB
fxCLYoSWCZyldvfXqMxDfLMPvoWyqmtgxhyQUlUFnqSTcYOMMtfkVelZNQxiuhaNbiJHTooxfgtUieJd
fPIqBrouYZptwIrinsLaJqYwvJrZVXjxHcLAXyueESfJfoojKrfXUAlxFLhVyAsGNkdWPYruDLBQCABx
cdQlMVAORsLjhVVbWimWGfsFIfRbuvgIQqrvbHJJqESpuOoYMYYOcfFsxQryYubhUxqLmHRVjnnOxtnW
XiTeGjioiqZvBEQtprlSilTPxowEuKwxqcZtsmrVKJPGTsONnmDVffwBqtXIMRgHLCQpQnCPOperVnLn
YWOLFtFymTSdseNCYKocVHYEpdxvJiHUXNVsffWLQdKTUbUtjILJoOVcrcXmFSDlwfKySmHLRmBOBUvr
gybEHFZdifOuNELUTNeSfYltJbqsXUdsBPBjAIcUoxmJBwZySMPHteLlBagscjobONNAeMwYwvaLHBOK
CKLbryDQRhVyNDFFwZYCAfStFcxVsumlYpIyWnqWKAydcHwtRjfvPxCckNBKPaKlNiOByWabMCojtPuN
bYRQikOGxBihqmJyjLfvOGVBGimSDQglXvlAEGhZFlZjyhWEUBNRZfosGXMEtAiUECjAZrZSGNFqMome
sXJmBLDNCAQvMMLpkEqHREGABSxurAZBJpvcgNRInHkdTYULYPVFhIvdEohnfAFbqPyiNjtJnydDmwwi
dajIGFIBEnPfTTqGShFkA
on this server.</p>
</body></html>

Original comment by msra...@gmail.com on 29 Aug 2014 at 12:43

[GoogleCodeExporter]

The first sendAndReceive and the check "if 
(checkForInputField(checkTextField)){" are not needed since the base class only 
calls the scan(HttpMessage, String, String) method if there's an input vector 
to attack. In fact, it prevents the attacks against the CGI app since no input 
fields are present in the response when the query parameter "pipenum" is sent 
(assuming that you are using the same app that you posted in the dev mailing 
list).

Could you try removing those statements and test again?

Regarding the message, that's expected when the input vector "URL Path" is 
selected. Is it selected?

Original comment by THC...@gmail.com on 29 Aug 2014 at 7:41

[GoogleCodeExporter]

No, I comment out the URL path call.  I have stripped the program down to its 
basics 

            msg = getNewMsg();
            setParameter(msg, param, randomCharacterString(2100));
            sendAndReceive(msg);

            HttpResponseHeader requestReturn = msg.getResponseHeader();
            String returnString = requestReturn.getHeadersAsString();
            log.debug("BASE baseResponseHeader was:" + returnString);
            HttpResponseBody responseBody= msg.getResponseBody();
            returnString = responseBody.toString();

            requestReturn = msg.getResponseHeader();
            returnString = requestReturn.getHeadersAsString();
            log.info("CGI Return Header was:" + returnString);
            responseBody= msg.getResponseBody();
            returnString = responseBody.toString();
            log.info("CGI Returnbody:" + returnString);

            bingo(getRisk(), Alert.MEDIUM, null, msg.getRequestHeader().getURI().getPath(), null, errorBufferOverflowMessage ,msg);
                return; 

I have also tried:

            HttpMessage newMsg = getNewMsg();
            setParameter(newMsg, param, randomCharacterString(2100));
            sendAndReceive(newMsg);
            HttpResponseHeader requestReturn = newMsg.getResponseHeader();
            String returnString = requestReturn.getHeadersAsString();
            log.debug("BASE baseResponseHeader was:" + returnString);
            HttpResponseBody responseBody= newMsg.getResponseBody();
            returnString = responseBody.toString();

            // This is where BASE baseResponseBody was you detect potential vulnerabilities in the response
            requestReturn = newMsg.getResponseHeader();
            returnString = requestReturn.getHeadersAsString();
            log.info("CGI Return Header was:" + returnString);
            responseBody= newMsg.getResponseBody();
            returnString = responseBody.toString();
            log.info("CGI Returnbody:" + returnString);

The results for both are:

35541 [ZAP-ActiveScanner-0] INFO 
org.zaproxy.zap.extension.ascanrulesAlpha.BufferOverflow  - CGI 
Returnbody:<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access 
/QbRUZDcbxTEOcSKJTWdWbosVHuvnnGQCNepTRETosyWYaduNisgxJbjTkZjQRXVCpWIuHiTRackdCtq
ZHODwXtFDlvEpeFQgUDUMQvnXFthawQmJKLMJjkpLknlDxJmGUsJPtlLlfBgXMnwsGduUTCvoulsdyEH
neKZnSGpKnNwbrUOpmuomKHvdpsrEcqFgQUMUgKCNjuvvIfUGhctcgHXDNpVuyxygaeeJoRPLYQhYEWV
VkPZsNXkxEiqVLjYnxVVQdbLjPBElRqNRZPCUrtifIsDkhkHhiaNAEvQBwrjhPlOMBLGSgwxvoiPfslS
lQwIgttHDurBSaXoxyQhKPnsPoWtLQcDunTdCpCwdoLhBvtvUiyLXlIvAcWvjIZyvWqxDGBkMElwgYqp
uMZwtpFUYXAfVFtFStpCTNIfQaCFYOBqFWpoVlAvKLkBRolLVSCwWRyZsqGFWJZHiESBQqDrGFIDGWlH
vTogSUfUILHIumZtSINcmxVJqHfHomGhXiEefbKJGChsNaWXeaFoPSskDPdFSNveEMQejoihlBasdXdx
QTMhnnyGvxqtHCRkAlZTjrnTVPLZJQoOTvOdwIivabqDMlGYeODamECuimwdQMKiGTjOyArllDwmuZDV
kjctriydbouJoudXSZsRkJvNxiFhCUDFCmMPFHalUsMvOaxhUsPkuHZRPFertbFWlsLBdJvnLDjnmDcu
SAeJgDDRpdDkXteVTxQkmNaZTpUxAkgiUXwpCdVcMxTPidQADnWIkEnhnwhqCThMFMhRiPAAdwCDBFNj
hrErEvlvsgBSowZrEBHHdXKAdjNaaVsHMtsQTGBiuXAfbdvNnFCemrflCNWWHXSRDuBoXsVnVVUxNpDP
rbxTvWrkUtRWvCkFsMbEHtqYRFpVOStHyvUSlNJKavwYytJBOwqERKvwEfjgtiGXBsvOUEIQasGcgmff
vssHqdJpKUvOxHPpJPwfnlbCtsQFTqFfZbiQiXncfEcSlOxsEFRkaStdOvUhkAPyyOmcEtIEHuYYuhDd
OCdhPlYgPTrQkwDsQfNVKdcgIsZNGNsljNMUMSdsFDqhhHkykJWwalhrJQUqgVkSVcVtgsLrQbxIxxUk
UQVNtTOdnJVbjDbgRZHEKHUvpRuuZpdnsqaGXOSDFVpfvoKVMhPNSDxEsIIDnkbJWfybhlmnfRIhGFYh
eMAMIPFgAhdSYuskdwZCGxcYCDkdoxKEcuCJxqrrbTnZKSKhfqMxYRoRKqtKYOXlhXEVQwAiqppocJVx
TgqBfidMmOabOBPYidBaBifRkHpNOrEwiZyELlFakOyAwKNUDHbQpVYgjsBbVSHpTlHYoIESviXePmpp
WmygfGyEijSJMNSoQmjwPaTgkxlbjZqVuFxVaxKjaMNPQbMKSkOCZoyGeuuYmodmxojKIgbinATYehwT
NFbkhESMyirKVPsjafoJHJHQyHCbAaLtJvfGjVitPMumFjPagYlcupfmMsakHVJMAxKwwmNJgeorUIVu
xNojqDXKFlGaPWcNgNFvPHIynUsYbrhhOtqijuOTHaJdWbxFJqMMKjAcyGJxZIEMnOgxiWSVfemUtnFY
cZBvXjcBiRsIsQbxgaPYZiYAgNkkmbpXZiuLrOIhCHwDSAaVUDlsoHAOUQnQhRaTfTrVtUhGsdHbKQWv
yxIWxZKdMrnxCSDXDvAbMTqfmkcKSCKygjhkSnEaqPLyJDLtNUGpHBTkdAhQZvvCVoOisUDLrRsvwHdG
JXQoQrdvFpwOQJFLRbBOadyRfRnxYCMLEgohbREcKYvRVcsiJWUJEMNxTDokqEcKlXZnqsnERkoxuaBN
CLnatGnOiZeMmlXUUXayXjhNWPagjmpeASNXfRUvbxNCBjhJROMDUNGpVEiQgVsKqVwXaNkGraDKrqHt
FwSOMBmhoUnDtGwxnODOfkjvMUavLQxvywmFIuQHQUEnBxNRlMxaEcoIMqgpUxyqtXLhtjCsmMHJSUwN
YHxxsaoevVcUKXTyginQCDASjytIhAcElklgFtjnPSacSmvtfkUbJSatLTREWrUvJfgwEcrjWKMmOZen
uIXOBseZSyJsIDJaOVaTL
on this server.</p>
</body></html>

Original comment by msra...@gmail.com on 29 Aug 2014 at 3:43

[GoogleCodeExporter]

The "URL Path" that I was referring to is in the options "Active Scan Input 
Vectors" > "Injectable Targets", you should deselect it (if it's selected) 
since it's not required for this test, also make sure that the input vector 
"URL Query String" is selected.

Are you submitting the form before starting the scan?

Original comment by THC...@gmail.com on 1 Sep 2014 at 7:58

[GoogleCodeExporter]

Well, your solution seems to work with the following caviets.  It does not work 
with the initial automatic scan (attack), but if I manually select it under 
advanced active scan it works fine.  I can work with this.  Now to the next 
question, how do I get the thing to not automatically run under the attack 
button setting.  It's not a major deal, but I like to make it clean.

Thanks for the help.  The solution was not obvious.

Original comment by msra...@gmail.com on 1 Sep 2014 at 9:17

[GoogleCodeExporter]

>[...] initial automatic scan (attack), [...]
Are you referring to the "Attack" button of the "Quick Start" tab?
If the form is submitted and the scanner is enabled (i.e. has alert threshold 
other than "OFF" in the "Policy" dialogue) it should be running/working.
If that's the case and it's not running, could you provide the exacts steps to 
reproduce that?

>[...] to not automatically run under the attack [...]
Is the "not" intended?

Original comment by THC...@gmail.com on 4 Sep 2014 at 7:35

[GoogleCodeExporter]

Ok, let me try fro a better description.  If I use the attack button under
the quick start tab, the plugin runs but does not operate properly.  It
does not try and run any of the cgi parameters but just sends the random
character string back to the server as a URL, in other words it does no
tree traversal.  If I do an "Active Scan Input Vectors"  and select the URL
to scan it works fine.  There is something in the quick start attack tab
that is causing it not to work.

Original comment by msra...@gmail.com on 7 Sep 2014 at 3:08

[GoogleCodeExporter]

Sometimes a picture is worth a thousand words.  Let me add some screen captures 
that may make it easier.

The first image is what happens when I select the attack button.  It inserts 
the randomstring as being the url to which I will be attacking.  Next I select 
advanced active scan.  That is image #2.  I select the CGI script directory 
(image 3) and get the desired result when I do the new scan from advanced 
active scan, image 4.

If I select index.html as the startpoint, it just gives me the same result as 
if I had pressed the attack buttion.  What am I missing.

Original comment by msra...@gmail.com on 7 Sep 2014 at 5:32

Attachments:

• [initial scan.jpeg](https://storage.googleapis.com/google-code-attachments/zaproxy/issue-1299/comment-22/initial scan.jpeg)
• [advanced active scan.jpeg](https://storage.googleapis.com/google-code-attachments/zaproxy/issue-1299/comment-22/advanced active scan.jpeg)
• select.jpeg
• [new result.jpeg](https://storage.googleapis.com/google-code-attachments/zaproxy/issue-1299/comment-22/new result.jpeg)

[GoogleCodeExporter]

OK. Could you try attack http://localhost/ instead of 
http://localhost/index.html ? If you attack the latter it will not attack 
sibling nodes like "cgi-bin".

Could you attach your latest code?

Original comment by THC...@gmail.com on 23 Sep 2014 at 8:12

[GoogleCodeExporter]

Well, I tried your chage of attack to http://localhost/ instead of 
http://localhost/index.html, and that fixed it.  I will post a corrected code 
in the next couple of days.

Original comment by msra...@gmail.com on 25 Nov 2014 at 1:24

[GoogleCodeExporter]

Any update?

Original comment by kingtho...@gmail.com on 27 Nov 2014 at 2:01

• Changed state: Started

[GoogleCodeExporter]

Original comment by kingtho...@gmail.com on 27 Nov 2014 at 2:04

• Changed state: Duplicate

[GoogleCodeExporter]

I'm planning on posting it on Monday. 

Original comment by msra...@gmail.com on 27 Nov 2014 at 3:11

[GoogleCodeExporter]

Attached is the latest version to be considered for Alpha release. It works 
against the test cases I have built.  

Original comment by msra...@gmail.com on 30 Nov 2014 at 9:54

Attachments:

• BufferOverflow.java

[GoogleCodeExporter]

Some minor comments:
 - Consider not logging the random chars as that creates a lot of "noise", maybe log the final generated string?
 - Consider using the class (org.apache.commons.lang.)RandomStringUtils to generate, at least, the "normal" string.

You now have commit access, can you go ahead with the commit (and mark the 
Issue 1297 as Committed)?
Thank you for contributing :)

How would you like to be credited? 
https://code.google.com/p/zaproxy/wiki/HelpCredits

Original comment by THC...@gmail.com on 5 Dec 2014 at 11:48

[GoogleCodeExporter]

Simon

Thanks.  If you want to credit me, just stick me in which ever team you
want, using the name Mark Rader.  I have changed the logging of random
characters, as that is no longer needed at this time for debugging.  I'll
probably do a new version using org.apache.commons.lang for the next
release.  I have a couple of more ideas of things to add.

Also, if you could direct me as to commit instructions as I have never used
SVN under an IDE, I am more used top command lineand which branch you want
the Alpha code put in.

Mark Rader

Original comment by msra...@gmail.com on 6 Dec 2014 at 10:07

[GoogleCodeExporter]

A few minor things that it would also be good to fix:

getRisk() should return MEDIUM instead of LOW (as per the alert raised)
getCategory() should probably return INJECTION
getId() should return something else - the 60000 series are really for 
examples. Based on the comments in the file maybe 30001?

Many thanks,

Simon

Original comment by psii...@gmail.com on 8 Dec 2014 at 12:04

[GoogleCodeExporter]

Sure. I'll get those changed tonight. 

Original comment by msra...@gmail.com on 8 Dec 2014 at 12:33

[GoogleCodeExporter]

Some comments:
 - The scanner needs to be declared in the ZapAddOn.xml file [1], otherwise it will not be loaded;
 - Consider updating the help file [1], with a description of what (and how) the scanner does.

[1] 
https://code.google.com/p/zap-extensions/source/browse/branches/alpha/src/org/za
proxy/zap/extension/ascanrulesAlpha/ZapAddOn.xml?r=1713#24
[2] 
https://code.google.com/p/zap-extensions/source/browse/branches/alpha/src/org/za
proxy/zap/extension/ascanrulesAlpha/resources/help/contents/ascanalpha.html?r=17
13

Original comment by THC...@gmail.com on 8 Dec 2014 at 4:36