-
-
Notifications
You must be signed in to change notification settings - Fork 673
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
selenium: add open custom request in browser feature #4155
base: main
Are you sure you want to change the base?
selenium: add open custom request in browser feature #4155
Conversation
Wait ... now why did Java 18 fail? |
You need to suppress the serialization thing in some UI classes. Search PRs a bunch were done at one or two points. |
Got it... Apparently its there in this extension itself :)..... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussions regarding PopupMenuItemOpenCustomRequestInBrowser :)
...rc/main/java/org/zaproxy/zap/extension/selenium/PopupMenuItemOpenCustomRequestInBrowser.java
Show resolved
Hide resolved
848061d
to
7d11572
Compare
this can be tried out now :)... just needs unit tests and help docs for completion. |
Do you need advice on local testing or something? Is there a way we can help you cut down on pushes of small discrete changes? |
It was passing locally but failing in CI. |
Oh okay. |
Ahh finally :) |
ad38613
to
cd4513b
Compare
Helps in viewing a custom request with a browser. Signed-off-by: ArkaprabhaChakraborty <chakrabortyarkaprabha998@gmail.com>
cd4513b
to
5131bda
Compare
ping @thc202 @kingthorin @psiinon :) |
I appreciate your honesty 😀 |
Code seems okay to me. I'm not sure I follow the force https part. I'll try to build this branch tonight and test it. |
The changelog and help should be updated. |
...rc/main/java/org/zaproxy/zap/extension/selenium/PopupMenuItemOpenCustomRequestInBrowser.java
Outdated
Show resolved
Hide resolved
} | ||
return null; | ||
} catch (Exception e) { | ||
throw new ApiException(ApiException.Type.URL_NOT_FOUND, e); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ended up with a ton of 1286162 [ZAP-IO-Server-1-17] WARN org.zaproxy.zap.extension.api.API - Request to callback URL https://demo.testfire.net/zapCallBackUrl/images/home2.jpg from 127.0.0.1 not found - this could be a callback url from a previous session or possibly an attempt to attack ZAP
while testing. I guess this is due to media included in the custom request I was opening? It's awfully chatty/loggy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't understand how you got this :)..... the hist param didn't get appended :).....
} catch (Exception e) { | ||
View.getSingleton().showWarningDialog(e.getMessage()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I seemed to hit the exception case more often than not.
I browsed to demo.testfire.net clicked a few pages, submitted the login POST with any old values. Then tried to open a few of the things via the new menu.
I don't really understand what's "Custom" about it, but simple GETs seemed to work while other GETs failed, and the one POST I had to work with never worked.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay so for the POST requests, I think we need to follow the redirect/"follow the lead" to the very next GET request. Actually, I guess this was the same concern in the issue itself. I did need some views on what could be done. The main "concern" was to send modified headers and load the "result" in a browser to kind of verify/view the exploit/vulnerability.
I think I'm failing to grasp what this is supposed to be doing. I see the URL being replaced partially by a built callback URL but the content loaded is sometimes/generally the URL/request I've asked for. For example if I "Open Custom Request in Browser" from the Sites Tree against http://demo.testfire.net/login.jsp in Firefox the page is displayed and tells me my Login failed 🤷. So it seems to be loading the right page but the display in the address bar is |
Did you try it with some new headers or cookies? :) |
Most of the GETs that have a status 200 in the requestor/ request/response can be opened by this option. The fundamental difference is that this option can send in "modified" headers and cookies which is not quite possible for a normal browser. Also for "cache poisoning" attacks involving the usage of a header/cookie as a cache buster and a header/cookie as a vulnerable parameter... simply loading the URL using a browser doesn't help as it doesn't load the isolated vulnerable PoC which has been created in the cache with those cache busters... kinda helpful if we don't wanna poison the entire "base" cache response to which normal users are usually directed :P |
Added when/how? I’m not prompted. Like I said I dunno how this is meant to work. |
In the requestor... simply modifying it? :) |
Please tell me how users are meant to use this. I’m currently accessing it from the Sites Tree. If I have to use Requestor first I’m going to send the request from Requestor how is that going to have an impact on my use of this? I’m so confused and this is seeming VERY un-intuitive. |
You don't have to use the "send". Just to modify the request I mean.. I have to check the cases/ GET requests for which it's failing and decide a method for POST requests. |
I'm still missing something here. I'll try to get time over the weekend to do a screen grab so that you can see how it's behaving for me. |
Had a talk with @kingthorin :). It didn't misbehave anymore :P. The POST request works well, tried it out on three CTF and got the flags with ease :). |
Okay upon testing with http://demo.testfire.net/login.jsp The login request was a POST request, with the following: Req Headers
Req Body
Response Header
|
Probably this mess-up is happening because of the moved temporarily and it's followups :) |
|
Following through the redirect with the URL is what's causing the problem |
So when we hit a redirect the URL should be changed back to the actual URL and shouldn't stay as zapCallBack |
Now how da hekkk should I do this :)... webdriver.get() is what's used by the "getProxiedBrowser" :)... Can't have a selenium addition gotta do it with whatever we have :) |
If we have a redirect..... then kinda replace the URL in a "breakpoint-ish" fashion... that's what's coming in my mind |
What happens if you re-write the Doesn't help for meta or js redirects, but it's a step. |
Rewrite? Like rewrite after I get the 302? And not follow the redirect automtically like its happening now? |
I mean the user is selecting a message to open in the browser and we're feeding it from ZAP. So we know what msg is it. Just get the location header (from the response), extract the value. Set |
Wait ... wouldn't the browser redirect to /locationzap or /locationbroken then? |
Sometimes we will... other times it can be a direct send... like not just a replay from ZAP's stored History |
So if the original was |
Ahhh got it :) but will it help the case? IT will stop the error but :) |
Actually, I don't really wanna stop the redirect... I want it to play it out... It's kinda like the "rendered" view in burp actually |
Well it'll mean the redirect doesn't happen which I thought was your goal. I guess it depends when/how it's coming up. Is it when the original was a redirect, or is it when the original worked but "now" it's redirecting (because of an invalid session or csrf or ______)? Edit: You already have handling detecting if it should be direct or cached when opening. This should just be an additional step shouldn't it? You should be able to figure out the conditions that lead to the situation(s) and build around them. Even if for some requests we have to refuse to open them (just show a warning dialog instead ... or "for now") 🤷♂️ |
did figure that out as well ... for the test site if you login successfully you enter the "dashboard", else, you're redirected to the login page aka login.jsp |
TRUEEEEE BIG BRAIN MOMENT!!!! XD |
nope it didn't quite work |
So even for the "correct" login apparently there is a redirect which I missed :).... it redirects to the |
Signed-off-by: ArkaprabhaChakraborty <chakrabortyarkaprabha998@gmail.com>
Signed-off-by: ArkaprabhaChakraborty <chakrabortyarkaprabha998@gmail.com>
Has conflicts |
I think this one will be dropped. We couldn't decide a correct action for POST requests |
@ArkaprabhaChakraborty are you wanting to see/work this through to completion if we can settle on the POST behavior? |
Yes 💯. I kinda need it. Even the POST functionality (I have only
encountered GET situations but POST is a necessary one). But POST is just
one of them. PUT, DELETE and other situations is waiting to catch us by
surprise :).
…On Tue, Aug 1, 2023, 5:04 PM Rick M ***@***.***> wrote:
@ArkaprabhaChakraborty <https://github.com/ArkaprabhaChakraborty> are you
wanting to see/work this through to completion if we can settle on the POST
behavior?
—
Reply to this email directly, view it on GitHub
<#4155 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AN6F3GMIYIH5OU5VIMUZDBDXTDSWHANCNFSM6AAAAAARKQ45P4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Related to: zaproxy/zaproxy#1456
Signed-off-by: ArkaprabhaChakraborty chakrabortyarkaprabha998@gmail.com