I am looking at a bug in WebSVN where when I get into a file log and click on compare, it looses the repository name as part of the request. The details are unimportant.
However, I've tracked down the bug to a http form that looks like this:
<form method="get" action="comp.php?repname=Binaries&" id="compare">
....
<input type="hidden" name="KEY" value="VALUE">
Is this supposed to work? Will both the "repname" argument, specified as part of the URL, and the hidden value be sent? It seems Chrome 4.1 only sends the hidden argument, and removes the repname parameter altogether. Is this correct?
I fixed it temporarily, pending more information, by adding another hidden field for repname with the same value, and now everything works, I'm just wondering if Chrome or WebSVN is in fault here.
you should remove the & from the end of the action value, that will likely just cause you trouble. if you need to pass an ampersand through, you should url-encode it as %26
edit: you should definitely do it the way you fixed it - by passing repname as another hidden variable - since some browsers do have weird behaviour when dealing with explicit and implicit url vars in a get :)
Related
I'm working on some interesting APIs that have a "?" in their path, like so:
/api/?other/stuff/here
However, if I type "?" in the request URL in Paw, it automatically moves my cursor into the query parameter fields. Is there a way to disable this? I'm forced to use postman at the moment to work around this, which is less than ideal.
Nevermind, using %3F instead fixed the issue
As mentioned before, using %3F should work nicely!
Another, more generic way is to use the URL-Encode dynamic value:
Right-click on the field where you want to insert the special character and pick Encoding > URL-Encoding > Encode
A popup opens and you can type your special character (here ?) in the Input field. You should see the preview of the encoded value at the bottom of the popup.
Continue to type the end of the URL after this dynamic value. And you should be good to go!
I'm a newbie but I think Paw can do what i need :
I need to extract a session id behind a login page.
I go to https://admin.booking.com, filling the form (login and pass) and the landing page behind includes a session id :
https://admin.booking.com/pc/index.html?ses=xxxxyyyyyzzzzz11112222233333
I'd like to :
1) Push credentials with Paw as part of my request,
2) get the above item (ses) item as a response so i can use the php script extension provided by Paw and then call this script "on demand".
Is this possible ? If so, what should i do ?
Thanks for your help
UPDATE*: we've added a documentation article to describe the process a little more: Login via a web form in Paw. We've detailed the process to deal with CSRF tokens too.
Paw isn't quite yet ready for handling web/HTML forms. Though, there's one way to do it the right way: if you inspect the form with the Chrome dev tools you'll find the name of the input from the DOM/HTML:
In your case, you have the inputs: loginname, password, lang.
Also, find the <form…> tag to see what's the action attribute. If there's no action attribute (like in your example), it means the target URL for your form is the current page's URL (https://admin.booking.com/ in your case). Also, make sure the method="POST" is also there in the <form…> tag, otherwise this method won't work.
Then jump into Paw and set:
URL (in your case https://admin.booking.com/)
method to POST
go to the Body tab and use "Form URL-Encoded + fill up the fields from your form
If all works, you'll see Paw show a redirection request, and if you go to the right-hand side panel under "Response" > "Headers", you should see a Location header with a value similar to the URL you initially mentioned (https://admin.booking.com/pc/index.html?ses=xxxxyyyyyzzzzz11112222233333). Hurray! You got your value into Paw!
Now that you have that, you can create in a new request (click on the + button at the bottom of the left-hand side list). And wherever you want to use this session token/ID, you can insert a dynamic value to retrieve that URL value. You have more infos here, in our docs, but I'll describe the steps here:
On whichever field you want to insert the token, right-click and pick Responses > Response Header.
Make sure you pick the first request in the "Request" dropdown menu, and enter Location in the "Header" field:
You should see the value of the Location header of the previous response appear here.
Now what you want to do is to extract only the part you want (i.e. the value of the ses param in your case). For that you'll need that extension for Paw, so please install it now: https://luckymarmot.com/paw/extensions/RegExMatch
Copy the dynamic value you have just inserted (the blue token), and right-click on that field to insert a new dynamic value, and pick Extensions > RegExp match:
In the Input field, paste the previous dynamic value you copied. And use the RegExp field to write a regular expression that will successfully extract the part of the URL you want (this should work in your case ses=(.*)).
Now that you're set up. You should be able to use this little new blue token wherever you like and automagically extract the value from the previous form. And whenever you send again the initial request, and get a new token, everything else will also update! :)
It was a little long guide, but I hope this will help you and hopefully others too.
what is the best way of passing querystring to another page, i would definitly avoid like using.......
<a href="Page2.aspx?WONumber=12345">
is there any better way?
i was thinking create a Baseclass with few prop and update the baseclass?
thanks.
It sounds like you want to take the querystring argument, and use it in subsequent pages.
If it's not desirable to pass-forward this querystring argument from your current page, perhaps it's called page1.aspx, without using another querystring parameter, you could:
store the value in Session. Consider Session["WoNumber"] = Request.QueryString["WONumber"].ToString();
store the value in Cookies. You could use something like: Response.Cookies["WoNumber"].Value = Request.QueryString["WONumber"].ToString();
It really depends on where you're getting the value from. You can build a URL using UriBuilder or if it's simple enough string concatenation could be OK (though you'd have to make sure to Server.UrlEncode the values).
If the value is a constant, as your example implies, then there is nothing wrong with putting it directly into a query string, although I would still use a proper named constant, eg.
<a href="Page2.aspx?WONumber=<%= TheMagicOrderNumber %>
with the constant defined in the code-behind:
protected const int TheMagicOrderNumber = 12345
If your objection is the maintainability of "magic string" URLS, and you'd be prepared to use a button instead of an anchor, you could do worse than
<form method="GET" action="Page2.aspx">
<input type="hidden" name="WONumber" value="12345" />
<input type="submit" value="Navigate" />
</form>
this method will generalise to a query string of any complexity with any number of parameters.
There is a great article I came across a few months ago when I was looking for enhanced security with querystrings...
http://devcity.net/Articles/47/1/encrypt_querystring.aspx
It's a very good article, and has a bonus the author offers code examples in C# and VB.NET.
There are times when I prefer to use querystrings over sessions... small number of session objects is ok, but too many and it starts to become a bit tedious to debug problems.
You can encrypt a querystring parameter, if security is your concern.
Or you can use other holders, such s p.cambell says above (session & cookie).
You could also store it in a database, and have the page you go to retrieve it onload.
Just depends on your application requirements.
Another thing I've done is to use <asp:panel>, basically using a single page as though it were multiple pages. In this way, I also have access to viewstate to hold my variables. (Whenever a user clicks 'next', or whatever they would click to goto the next page, I simply hide the panel they're on, and show the panel they want to go to [visible = true/false] property)
Should we guard against unanticipated user input from dropdown lists? Is it plausible to expect a user to somehow modify a dropdown list to contain values that weren't originally included?
How can they do this and how can we stop it?
Absolutely check for that.
Do something like this pseudo code on the receiving end:
if { posted_value is_element_of($array_of_your_choices) }
//processing code
else {
//prompt them for good input
}
So for example: Your dropdown list is of Primary Colors they'd like their house painted. You'd have (in PHP)
$colors = array('red', 'blue', 'yellow');
if in_array($_POST['color'], $colors)
{ //process this code! dispatch the painters; }
else {echo "sorry, that's not a real color";}
Edit: This is certainly possible. If your values are being submitted via a GET request, then the user can simply enter www.example.com/?price=0 to get a free house. If it's a POST request, it may seem a little more difficult, but it's really not:
curl_setopt($ch, CURLOPT_POSTFIELDS,"price=0");
People could just use cURL to directly manipulate a POST request, in addition to a trivially large number of other clients.
A user can simply hand-write a HTTP request which has has filled in malicious data. For GET requests, for example, you may have a "State" dropdown that lists Alabama, Arkansas, etc. He may put http://example.com?state=evilstuff just simply into the browser url bar.
This is easily prevented since you already know exactly what is in the dropdown list. Simply checking to see if the input is in that list or not should be sufficient to prevent against injection-like attacks. If he puts in something other than a valid state name, throw an error.
This can only be done by modifying the HTTP response. So,
yes, it can be done and you need to safeguard against it (i.e. check if this can be a security threat and, if yes, validate the input), but
no, you don't need to bring a "nice" error message, since this cannot happen to a normal user "by accident".
When I'm bored, I edit drop-down lists in web sites just for fun. Mostly it just breaks the site, but at least once I could have gotten free or drastically reduced prices on tickets just by playing with the site's hidden fields. (Alas it was for a company I worked for, so I had to instead report the bug.)
Yes, a malicious user can submit data to your server without ever using your form, and could submit data that's not normally included in your dropdown list. This is a trivial form of attack that's often exploited in the real world.
Always check for valid input!
Some of the other answers are absolutely correct, you MUST validate on the server-side ANY data coming from the user side.
At work, we use tools such as the Firefix plug-in Tamper Data to manipulate and view data thats being posted to the server, after any client-side (javascript) validation has been done. Also, you can even use simple tools such as Firebug to visibly alter drop-down boxes to contain values that weren't put there by the server before submitting it.
I'm having a weird issue with an input type hidden and was wondering if anyone has ever seen something like this before. I'm saving about 2MB of data to a hidden field, in a comma separated format, then I'm posting that data to a jsp that simply sets some headers (so the output is recognized as an excel file) and then echoes the data.
I'm seeing that the variable that holds this data gets empty to the jsp side, even though I see that it's getting posted to the server (I'm seeing it with an HTTP sniffer) and all data seems to be contained correctly in the hidden field (I'm seeing that with firebug). However, if I change the object type to be a text area, the data is received correctly on the server's side.
Another weird thing I'm observing is that if I use URL encoding on the data, even using a text area, nothing gets to the server. If I don't use URL encoding but I have the hidden field, nothing gets saved to the field (it's empty when I check it with firebug). I don't understand that either...
I'm wondering if there is any special security setting that prevents the hidden fields to post big amounts of data to a Tomcat web server. Does anybody know anything about that?
If it makes any difference, I'm using the default enctype on the form (application/x-www-form-urlencoded)
I'm currently using a text are and setting the style to visibility "hidden" but it bothers me not to understand what's going on *sigh... Any suggestion is appreciated
I think having 2MB of data in a hidden field is a mistake regardless. You should store that kind of thing on the server as part of the session state, not send it back and forth between the server and the user, as you are doing. Instead, use a hidden field or cookie for the session variable*, which will be used to look up the 2MB of data.
*Don't do this by hand. JSP already has support for session state, among other things.
The server can't tell the difference between a textarea and textbox. All form elements are simply posted as name/value pairs.
Most likely, you have a double-quote somewhere in your data that's terminating the value attribute of the hidden input element. For example:
<input type="hidden" value="Double " quote" />
You need to escape the double-quotes by replacing them with "
<input type="hidden" value="Double " quote" />