We Keep Coding

fix for spot bug - HRS_REQUEST_PARAMETER_TO_HTTP_HEADER

I am executing below code inside servlet and getting this spot bugs - HRS_REQUEST_PARAMETER_TO_HTTP_HEADER
Bug: HTTP parameter directly written to HTTP header output in SSOIdpLogoutRedirect.doPost(HttpServletRequest, HttpServletResponse)
String relayState = request.getParameter("RELAY_STATE");
if(relayState != null)
{
response.sendRedirect(relayState);
}
To fix this bugs i added below code.
relayState = URLEncoder.encode(relayState,StandardCharsets.UTF_8);
But URL does not redirect in correct way as i can see the relaystate url has been changed after encoding
original relaystate = https://sad.ezhdj.net/system/web/apps/dfgh/
and after encoded it is
relaystate =https%3A%2F%2Fsad.ezdev.net%2Fsystem%2Fweb%2Fapps%2Fdfgh%2F`

you should use HttpServletResponse.encodeRedirectURL() to encode redirect urls:
String encodeRedirectURL(String url)
Encodes the specified URL for use in the sendRedirect method or, if
encoding is not needed, returns the URL unchanged. The implementation
of this method includes the logic to determine whether the session ID
needs to be encoded in the URL.
...
All URLs sent to the HttpServletResponse.sendRedirect method should be
run through this method...
this should work:
response.sendRedirect(response.encodeRedirectURL(relayState));
since your url doesn't actually need encoding, output from encodeRedirectURL() will be:
https://sad.ezhdj.net/system/web/apps/dfgh/
and the redirect will work just fine.
edit:
apparently proposed solution still triggers HRS_REQUEST_PARAMETER_TO_HTTP_HEADER spotbug error.
after doing little more research I found out that the error is meant to prevent HTTP response splitting vulnerability (i.e. when unwanted \r\n are written in the header section of http response).
we should then better sanitize relayState against this type of vulnerability.
a simple relayState.replace("\r\n", "") is enough to make the error go away:
response.sendRedirect(response.encodeRedirectURL(relayState.replace("\r\n", "")));

400 bad request after URL encoding

I am consuming REST web services in my java code. Before make call to Rest web service I am encoding my query parameters by java.net.URLEncoder
But by request is getting failed by 400 bad request exception
URL before encoding : host?limit=200&filter=published ge "2017-12-15T16:50:34.034Z" and (action.objectType eq "core.user_group_member.user_add" or action.objectType eq "core.user_group_member.user_remove")
URL after decoding : %3Flimit%3D200%26filter%3Dpublished%20ge%20%222017-12-15T16%3A50%3A34.034Z%22%20and%20%28action.objectType%20eq%20%22core.user_group_member.user_add%22%20or%20action.objectType%20eq%20%22core.user_group_member.user_remove%22%29
I am tried same from postman rest client tool there also without encoded url is working and encoded url failed with 400 bad request error.

"limit=200&filter=" doesn't need to be coded.

In postman you need to encode manually relevant parameters' values as follows:
Right click on a piece of selected text, and select “EncodeURIComponent” to manually encode the parameter value.

Url encoding issue with Jersey Client

I need to make a service call such as this:
http://myservice.com/path?var1=value1&var2=value2
The issue I have is value1 and value2 ends up getting encoded, and this makes the service call fail. For example, value1 is something like "a=b&b=c;2&&="... it contains special characters, basically.
I am guessing that this is an issue for the service to fix - to properly handle decoding encoded characters, which I do not think it is currently doing.
Here is a sample of how I am making these requests:
WebTarget target = client.target("http://test.com")
.path("path1")
.queryParam("var1", var1);
Builder builder = target.request();
...
What's puzzling to me is that if I make the same request just using Chrome, everything works. So that makes me to believe that I should have some way with the Jersey API of "disabling" the encoding.

Only way I have found so far to use "raw" Url is to use URI.
So call like this
URI uri = URI.create("http://localhost/~Common~0#/edit?vadf&&sfs&&fdsfd=fs&fsd");
WebTarget target = client.target(uri);
You get request url
1 > GET http://localhost/~Common~0#/edit?vadf&&sfs&&fdsfd=fs&fsd
Everything else I tried resulted in encoding special characters.

Extracting ViewState when testing JSF with JMeter

I'm using JMeter to do some load tests on my JSF application and I'm having trouble passing the ViewState along the pages. The ViewState variable doesn't get extracted at all or it doesn't get passed along the pages.
I've recorded my test steps with a proxy server and this is what it looks like:
I've added the Regex extractor in the first GET request. Tested the regex and it is correct.
In every POST request I replace the hardwired View IDs with my variable.
And what I get when I send the request is the following:
The POST parameters are incorrect, as it sends the name of the variable.
POST data:
loginForm%3ArequestToken=&loginForm%3Ausername=heller&loginForm%3Apassword=%21QAYxsw2%A7EDC&loginForm%3AloginButton=Anmelden&com.sun.faces.VIEW=%24%7BjsfViewState%7D&loginForm=loginForm
Could you tell what I'm doing wrong here?
Thanks!

The ViewState parameter is an encoded value (Base64 I believe?) and may contain values that would be inappropriate if passed in a GET request through the url. URL parameters are typically encoded so that special values (Eg. space -> %20) can be represented and decoded when the request reaches the server.
The issue here is that the following request is a POST meaning that the parameters do not need to be URL encoded.
com.sun.faces.VIEW=%24%7BjsfViewState%7D&loginForm=loginForm
The above shows that JMeter or some other process is URL encoding the ViewState in the request which is incorrect. The value of the ViewState should simply be sent as is.

Found my problem: the regex was wrong, so it couldn't find anything in the response. I had to change the regex. Noticed it after adding a default value "NOT FOUND".

Encoding of Response is incorrect using Apache HttpClient

I am calling a restful service that returns JSON using the Apache HttpClient.
The problem is I am getting different results in the encoding of the response when I run the code on different platforms.
Here is my code:
GetMethod get = new GetMethod("http://urltomyrestservice");
get.addRequestHeader("Content-Type", "text/html; charset=UTF-8");
...
HttpResponse response = httpexecutor.execute(request, conn, context);
response.setParams(params);
httpexecutor.postProcess(response, httpproc, context);
StringWriter writer = new StringWriter();
IOUtils.copy(response.getEntity().getContent(), writer);
When I run this on OSX, asian characters etc return fine e.g. 張惠妹 in the response. But when I run this on a linux server the same code displays the characters as ???
The linux server is an Amazon EC2 instance running Java 1.6.0_26-b03
My local OSX is running 1.6.0_29-b11
Any ideas really appreciated!!!!!

If you look at the javadoc of org.apache.commons.io.IOUtils.copy(InputStream, Writer):
Copy bytes from an InputStream to chars on a Writer using the default
character encoding of the platform.
So that will give different answers depending on the client (which is what you're seeing)
Also, Content-Type is usually a response header (unless you're using POST or PUT). The server is likely to ignore it (though you might have more luck with the Accept-Charset request header).
You need to parse the content type's charset-encoding parameter of the response header, and use that to convert the response into a String (if it's a String you're actually after). I expect Commons HTTP has code that will do that automatically for you. If it doesn't, Spring's RESTTemplate definitely does.

I believe that the problem is not in the HTTP encoding but elsewhere (e.g. while reading or forming the answer). Where do you get the content from and how? Is this stored in a DB or file?