I have GET request being sent to weblogic 12c server, which carries user info and on the server side i grab these
info to process the request.
And the GET request looks like below:
URL:/prem/JSP/xml/prems.jsp?username=rjanga&password=1234roh#&address=3450Rivast&city=FT+COLLINS&state=CO&zip=80526.
since i have a '#' symbol in my password weblogic server is ignoring it and anything after
it.
it only sees url as
/prem/JSP/xml/prems.jsp?username=rjanga&password=1234roh (ignoring the symbol '#' and all strings after it like address, city..etc)
After doing some research and going through this link i tried solution mention in it.
but it did not help, any help is appreciated.
You're going to have to do the encoding on the password field. Putting the password in the URL is HORRIBLY insecure. You shouldn't be doing it. That said, here is some info:
From http://java.sun.com/j2se/1.5.0/docs/api/java/net/URL.html :
The URL class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. Furthermore, because URL has no knowledge of URL escaping, it does not recognise equivalence between the encoded or decoded form of the same URL. For example, the two URLs:
http://foo.com/hello world/
and
http://foo.com/hello%20world
would be considered not equal to each other.
Note, the URI class does perform escaping of its component fields in certain circumstances. The recommended way to manage the encoding and decoding of URLs is to use URI, and to convert between these two classes using toURI() and URI.toURL().
It will be up to you to encode and decode those URL strings.
Related
I have a path like this:
GET http://aaa.com/invoices/{someType}/<bunch of optional query parameters>
It is okay to mix path parameters with regular query parameters in rest api?
Or better use required query parameters maybe there is better approach?
It is okay to mix path parameters with regular query parameters in rest api?
Yes. REST doesn't care what spelling you use for your resource identifiers -- any spelling that complies with the production rules described by RFC 3986 is fine. Information encoded into the URI is done at the server's discretion and for its own use.
From the perspective of a general purpose client, the identifier is the entire URI.
/a/b/c/d
/a/b/c/d?hasOptionalParameter=true
As far as REST is concerned, these are two different identifiers, and therefore two different resources. That you have a single endpoint for them is an implementation detail.
URI Templates allow you to describe "a range of Uniform Resource Identifiers through variable expansion." General purpose templates support variable expansion on both path segments and the query part.
But: one of the most familiar URI Templates is an HTML form; the processing rules for GET perform a replacement of the query part of the form action, but leaves unchanged the path segments. In effect, the path part of the form action URI is protected from change by the client, but the query part gets changed.
OWASP says "Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) will resolve Reflected and Stored XSS vulnerabilities" and "Applying context-sensitive encoding when modifying the browser document on the client side acts against DOM XSS" but how to differentiate between Escaping and Encoding? Another website says that Escaping is a subset of Encoding. I'm just confused between the two.
I set username and password from CSV file user:sysadmin, pass:"Pass#123456" but password is encrypted wrong upon request
User=sysadmin&Pass=Pass%40123456
The fact you see it as Pass#123456 doesn't necessarily mean that JMeter is sending wrong data, it might be either by intention due to string-based request representation in Raw form of request inspection in the View Results Tree listener or by accident (just a bug in it. You can check JMeter Issue Tracker to see whether similar issues were reported already)
In the mean time try switching to the HTTP tab of the View Results Tree listener:
Or double check what you're sending using a sniffer tool like Fiddler or Wireshark
But first of all I would recommend verifying your CSV data via Debug Sampler or temporarily switching to hard-coded (not parameterized) data to see if it resolves your issue.
# is encoded when sending HTTP request.
You need to add HTTP Header Manager with variable name Content-Type with value application/x-www-form-urlencoded,
This will tell the server that the values need to be decoded
I'm using SoapUI to automate tests against my companies APIs. I've successfully setup and run dozens of these cases.
This tyme, I'm getting an error which, after exhaustive tracking down, I've found is due to our APIs requiring the "#" char itself rather than the URL friendly "%40" substitution.
The post request I want is structured like this:
https://<endpoint>.com/<resource>?<param>&email_address#example.com
And what I'm seeing made is:
https://<endpoint>.com/<resource>?<param>&email_address%40example.com
How can I enforce SoapUI to use the char itself?
I've tried setting headers, media type and representations (though possibly not through all permutations).
Thanks.
Use Disable Encoding for the parameter.
My Web host has refused to help me with this, so I'm coming to the wise folks here for some help "black-box debugging". Here's an edited version of what I sent to them:
I have two (among other) domains at dreamhost:
1) thefigtrees.net
2) shouldivoteformccain.com
I noticed today that when I host a CGI script on #1, that by the time the
CGI script runs, the HTTP GET query string passed to it as the QUERY_STRING
environment variable has already been URL decoded. This is a problem because
it then means that a standard CGI library (such as perl's CGI.pm) will try to
split on ampersands and then decode the string itself. There are two
potential problems with this:
1) the string is doubly-decoded, so if a value is submitted to the script
such as "%2525", it will end up being treated as just "%" (decoded twice)
rather than "%25" (decoded once)
2) (more common) if there is an ampersand in a value submitted, then it
will get (properly) submitted as %26, but the QUERY_STRING env. variable will
have it already decoded into an "&" and then the CGI library will improperly
split the query string at that ampersand. This is a big problem!
The script at http://thefigtrees.net/test.cgi demonstrates this. It echoes back the
environment variables it is called with. Navigating in a browser to:
http://thefigtrees.net/lee/test.cgi?x=y%26z
You can see that REQUEST_URI properly contains x=y%26z (unencoded) but that
QUERY_STRING already has it decoded to x=y&z.
If I repeat the test at domain #2 (
http://www.shouldivoteformccain.com/test.cgi?x=y%26z ) I see that the
QUERY_STRING remains undecoded, so that CGI.pm then splits and decodes
correctly.
I tried disabling my .htaccess files on both to make sure that was not the
problem, and saw no difference.
Could anyone speculate on potential causes of this, since my Web host seems unwilling to help me?
thanks,
Lee
I have the same behavior in Apache.
I believe mod_rewrite will automatically decode the URL if it is installed, however, I have seen the auto-decode behavior even without it. I haven't tracked down the other culprit.
A common workaround is to double encode the input parameter (taking advantage of URL decoding being safe when called on an unencoded URL).
Curious. Nothing I can see from here would give us a clue why this would happen... I can only confirm that it is an environment bug and suspect maybe configuration differences like maybe rewrite rules.
Per CGI 1.1, this decoding should only happen to SCRIPT-NAME and PATH-INFO, not QUERY-STRING. It's pointless and annoying that it happens at all, but that's the spec. Using REQUEST-URI instead of those variables where available (ie. Apache) is a common workaround for places where you want to put out-of-bounds and Unicode characters in path parts, so it might be reasonable to do the same for query strings until some sort of resolution is available from the host.
VPSs are cheap these days...