I'm trying to pass a parameter containing space to a page.
When I look at the Request.RawUrl, I see that spaces are replaced by '%20' but why when I look at Request.QueryString spaces are replaced by '+' ?
How can I fix that so Request.QueryStringcontain space or at least '%20%' ?
Thansk for your help !
I found the following RFC:
https://www.rfc-editor.org/rfc/rfc1866
It states the following:
An HTML user agent begins processing a form by presenting the
document with the fields in their initial state. The user is allowed
to modify the fields, constrained by the field type etc. When the
user indicates that the form should be submitted (using a submit
button or image input), the form data set is processed according to
its method, action URI and enctype.
The default encoding for all forms is `application/x-www-form- urlencoded'. A form data set is represented in this media type as
follows:
The form field names and values are escaped: space
characters are replaced by '+', and then reserved characters
are escaped as per [URL]; that is, non-alphanumeric
characters are replaced by '%HH', a percent sign and two
hexadecimal digits representing the ASCII code of the
character. Line breaks, as in multi-line text field values,
are represented as CR LF pairs, i.e. `%0D%0A'." ... The user might edit the fields and request that the form be
submitted. At that point, suppose the values are:
name "John Doe"
gender "male"
family "5"
city "kent"
city "miami"
other "abc\ndefk"
nickname "J&D"
The user agent then conducts an HTTP POST transaction using the URI
`http://www.w3.org/sample'. The message body would be (ignore the
line break):
name=John+Doe&gender=male&family=5&city=kent&city=miami&
other=abc%0D%0Adef&nickname=J%26D
The previous note refers to Form Submission.
I believe that the .net method you are using is following the previous rules for some reason: seems to be processing the query string following the rules to process the Body of a POST request (note the John+Doe parameter). Perhaps you can specify that the method should process a GET request not a POST request? ¿Something in your request makes the method to process it as a POST?
Regards,
Related
I have a Paw related question.
Does anybody know how to extract a value from an encoded URL response field with Paw? The value is the only part of the encoded URL which starts with a %3D (the URL encoded version of an = sign).
Getting the dynamic values out of JSON, a JSON array, a URL, etc worked great.
You can use our RegExp Match dynamic value for this: https://luckymarmot.com/paw/extensions/RegExMatch
insert the RegExp Match dynamic value first
as input for RegExp Match use the Response Parsed Body dynamic value (with the key path to the url-encoded field with the id)
write the regular expression to extract the id from the field (see example in the screenshot)
Excellent point Natalia. Instead of the Regex extension I used the Substring extension. This worked perfectly as the size of the encoded URL never changed.
I know that URI supports the following syntax:
http://[user]:[password]#[domain.tld]
When there is no password or if the password is empty, is there a colon?
In other words, should I accept this:
http://[user]:#[domain.tld]
Or this:
http://[user]#[domain.tld]
Or are they both valid?
The current URI standard (STD 66) is RFC 3986, and the relevant section is 3.2.1. User Information.
There it’s defined that the userinfo subcomponent (which gets followed by #) can contain any combination of
the character :,
percent-encoded characters, and
characters from the sets unreserved and sub-delims.
So this means that both of your examples are valid.
However, note that the format user:password is deprecated. Anyway, they give recommendations how applications should handle such URIs, i.e., everything after the first : character should not be displayed by applications, unless
the data after the colon is the empty string (indicating no password).
So according to this recommendation, the userinfo subcomponent user: indicates that there is the username "user" and no password.
This is more like convenience and both are valid. I would go with http://[user]#[domain.tld] (and prompt for a password.) because it's simple and not ambiguous. It does not give any chance for user to think if he has to add anything after :
I am attempting to learn about XSS. I have one ASP page that has an input that POSTs to itself. The variable is URL encoded and displayed back to the user. Is this all that is necessary to defeat XSS?
If not, what would be an example payload that could defeat this?
It's enough to use HttpUtility.UrlEncode() to encode output URLs and HttpUtility.HtmlEncode() to encode input from the user or from other sources such as databases.
In the same time, control your input. If your variable has certain type (e.g. user name, numeric, etc) then do not let to enter html tags or "wrong" characters. Validate input type, length, format, and range.
http://msdn.microsoft.com/en-us/library/ff649310.aspx
I am using asp (JScript as my language) and working with getting data from a form that is sent using POST.
Specifically, I have a text input and I want to check if it was left empty. When leaving it empty, and including Response.Write(Request.form('opt2Dur')) in the called page, nothing prints (doesn't print null or undefined).
My thought was that it was just an empty string so I included this: Response.Write(Request.form('opt2Dur') === ''), however this printed false.
It will print true if I use Response.Write(Request.form('opt2Dur') == '') (== not ===). What is the true value that I can check against using ===? Or, in this case will it be sufficient to check with just ==?
Thanks for any help.
In scripting languages with "flexible" types and default values it's very easy to get confused with actual data types.
The actual type of each Request item (both QueryString and Form, it doesn't matter) is some sort of Array as it also supports more than one form element with the same name submitted to the ASP handler. It's mentioned in the documentation as well:
The Form collection is indexed by the names of the parameters in the request body. The value of Request.Form(element) is an array of all the values of element that occur in the request body.
Since the === also take into account type, it will return false in your case as array is not a string.
I wasn't able to find the exact actual type and reproduce it with local variable (it's not any plain array) so if you are keen on using the strict comparison operator, check the Count:
Response.Write(Request.Form('opt2Dur').Count === 0);
I need to allow the user to submit queries as follows;
/search/"my search string"
but it's failing because of request validation, as outlined in the following 2 questions:
How to include quote characters as a route parameter? Getting "Illegal characters in path" message
How to modify request validation?
I'm currently trying to figure out how to disable request validation for the quote character, but i'd like to know the risks before I actually put the site live with this disabled? I will not disable the request validation unless I can only disable it for the quote character, so I do intend to disallow every other character that's currently not allowed.
According to the URI generic syntax specification (RFC 2396), the double-quote character is explicitly excluded and must be escaped (i.e. %22). See section 2.4.3. The reason given in the spec:
The angle-bracket "<" and ">" and double-quote (") characters are excluded because they are often used as the delimiters around URI in text documents and protocol fields.
You can see easily why this is the case -- imagine trying to create a link in HTML to your URL:
<a href="http://somesite/search/"my search string""/>
That would fail HTML parsing (and also breaks SO's syntax highlighting). You also would have trouble doing basic things with the URL like emailing it to someone (the email client wouldn't parse the URL correctly), posting it on a message board, sending it in an instant message, etc.
For what it's worth, spaces are also explicitly excluded (same section of the RFC explains why).