Spring Boot: RequestRejectedException: The request was rejected because the URL contained a potentially malicious String ";" - spring

I get the following exception when I POST the login credentials for my Spring Boot app.
org.springframework.security.web.firewall.RequestRejectedException: The request was rejected because the URL contained a potentially malicious String ";"
It is posting to /dologin and then redirecting to /home with the jsessionid appended to the end. It does also set the session cookie too. I did not change any session settings and there is no mention of session in application.properties.
I tried to set
server.servlet.session.cookie.http-only=true
server.servlet.session.tracking-modes=cookie
As mentioned in https://stackoverflow.com/a/31792535/148844, but it didn't work.
I added
#Bean
public ServletContextInitializer servletContextInitializer() {
return new ServletContextInitializer() {
#Override
public void onStartup(ServletContext servletContext) throws ServletException {
servletContext.setSessionTrackingModes(Collections.singleton(SessionTrackingMode.COOKIE));
SessionCookieConfig sessionCookieConfig=servletContext.getSessionCookieConfig();
sessionCookieConfig.setHttpOnly(true);
}
};
}
But now it just POSTs, sets the cookie, and redirects back to the login screen. It's as if it can't access the session.
I set server.session.tracking-modes=cookie (instead of server.servlet...) and it is only using cookies now, but the Chrome browser is not sending the cookie back to the server after login! /home action will only re-display the login page if user attribute in the session is null.
POST /dologin HTTP/1.1
Host: localhost:8080
Origin: http://localhost:8080
Upgrade-Insecure-Requests: 1
Referer: http://localhost:8080/home
HTTP/1.1 302
Set-Cookie: JSESSIONID=3B82AAA40CE94FF490FBF7B4DBD837DD; Path=/; HttpOnly
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Location: http://localhost:8080/home
GET /home HTTP/1.1
Host: localhost:8080
Upgrade-Insecure-Requests: 1
Referer: http://localhost:8080/home
HTTP/1.1 200
Set-Cookie: JSESSIONID=B60BF649068F7E85346691FD2F5D119B; Path=/; HttpOnly
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Content-Type: text/html;charset=UTF-8
Content-Language: en-US
Content-Length: 2742
Date: Sat, 29 Sep 2018 17:41:55 GMT
Notice the cookies are different and Chrome did not send the cookie back to the server? Why?
Spring Boot 1.5.13, Chrome Version 69.0.3497.100 (Official Build) (64-bit)

OK changing server.servlet.session.cookie.http-only=true to server.session.tracking-modes=cookie and changing http://localhost:8080 to http://127.0.0.1:8080/ worked. I found this answer:
Chrome localhost cookie not being set
It seems Chrome keeps flipping from allowing localhost to disallowing localhost. It was working about a month or three ago. localhost is working for a Rails app and Chrome is sending the cookies.
In fact, Chrome is also sending the _mt_rails_session Rails cookie for localhost to the Spring Boot app, but never the JSESSIONID cookie.
I suspect, but have not confirmed, it may be due to setting up HTTPS on port 8080 for an unrelated 3rd Spring Boot app, and there may be some HSTS setting cached in Chrome internals. It's probably a bug in Chrome.

Related

Setting spring.jpa.open-in-view=false makes API responses inconsistent, giving 500 error to client

Since I started working on a spring-boot application, I use to see the following warning during service startup
2022-09-20 17:59:49.061 WARN 10776 --- [ main] aWebConfiguration$JpaWebMvcConfiguration : spring.jpa.open-in-view is enabled by default. Therefore, database queries may be performed during view rendering. Explicitly configure spring.jpa.open-in-view to disable this warning
To address this, I recently added the spring.jpa.open-in-view=false in application.properties file to disable this warning and it worked.
However, after doing so, some of the endpoints became inconsistent in sending the response! For instance:
User-1 requesting an endpoint gets HTTP/1.1 200 response w/ JSON body
User-2 requesting the same endpoint gets HTTP/1.1 500 response w/o any body
Ideally, both the requests should fetch a JSON response body having list of Objects (different objects based on user)
In chrome's network tab, I see the following response for User-2
HTTP/1.1 500
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 820
Date: Tue, 20 Sep 2022 12:43:55 GMT
Connection: close
There are no warnings, errors, exceptions of any sorts logged in the server log. From the start of the function execution till the returning of response, all the logs seen are expected ones.
The same User-2 making the same request when spring.jpa.open-in-view=true will fetch the following response (and 5 Objects in the list).
HTTP/1.1 200
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
Access-Control-Allow-Origin: *
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY
Content-Type: application/json;charset=UTF-8
Transfer-Encoding: chunked
Date: Tue, 20 Sep 2022 12:52:04 GMT
Is there any related configuration that needs to be done along with spring.jpa.open-in-view=false setting?
Also, should I really need to worry on changing the default value? How will this setting impact the application?
My environment info:
Java: 1.8
MySQL: 5.7
Spring-Boot: 2.1.2.RELEASE
Spring Tool Suite: 3.9.9.RELEASE
All the queries are in #Query annotation in extended JpaRepository interfaces.
application.properties:
logging.level.org.springframework.web = INFO
logging.level.org.hibernate = INFO
logging.level.my.packages = TRACE
spring.jpa.hibernate.naming.physical-strategy = org.hibernate.boot.model.naming.PhysicalNamingStrategyStandardImpl
spring.jpa.properties.hibernate.dialect = org.hibernate.dialect.MySQL5InnoDBDialect
spring.datasource.url = jdbc:mysql://localhost:3306/dbname
spring.datasource.username = username
spring.datasource.password = password
I'm trying to understand the reason behind this unexpected behavior. Any info could be helpful.
Thanks

Cannot bypass Dynamic status cache for my APIs in Cloudflare

After defining the following configuration to avoid dynamic caching for an API : Cloudflare for your API
My calls are still in a Dynamic cache status. You can see the received reponse headers :
access-control-allow-methods: GET,OPTIONS
alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400, h3-28=":443"; ma=86400, h3-27=":443"; ma=86400
cache-control: no-cache, no-store, max-age=0, must-revalidate
cf-cache-status: DYNAMIC
cf-ray: 698eeac5ae5640cf-CDG
client-control: max-age=43200, s-max-age=43200
content-encoding: br
content-type: application/json
date: Mon, 04 Oct 2021 13:57:03 GMT
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
expires: 0
pragma: no-cache
server: cloudflare
strict-transport-security: max-age=31536000; includeSubDomains; preload
vary: Origin,Access-Control-Request-Method,Access-Control-Request-Headers, Accept-Encoding
x-content-type-options: nosniff
x-frame-options: DENY
x-xss-protection: 1; mode=block
Here's the configuration i've done
Do you find a way to get a 'BYPASS' cache Clouflare Status Headers
If your goal is to avoid having your API calls cached, then the above page rule looks correct. You are using a Cache Level directive to Bypass the caching logic.
This means that all the calls matching the URL pattern will always be pulled from your origin server. This is confirmed by the cf-cache-status response header valued with DYNAMIC
From the documentation
DYNAMIC: Cloudflare does not consider the asset eligible to cache and your Cloudflare settings do not explicitly instruct Cloudflare to cache the asset. Instead, the asset was requested from the origin web server.
The response header cf-cache-status can also have a value of BYPASS, but this happens in other scenarios (also described in the documentation)

Safari set-cookies not working for first party cookie

When I login, I return to the browser:
Overview
URL: https://subdomain.domain.de:8444/api/auth/login
Status: 200
Source: Network
Adresse: xxx.xxx.x.xx:8444
Initiator:
xhr.js:177
Request
POST /api/auth/login HTTP/1.1
Accept: application/json, text/plain, */*
Content-Type: application/json;charset=utf-8
Origin: https://subdomain.domain.de
Content-Length: 62
Accept-Language: de-de
Host: subdomain.domain.de:8444
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1 Safari/605.1.15
Referer: https://subdomain.domain.de/login
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Response
HTTP/1.1 200
Access-Control-Allow-Origin: https://subdomain.domain.de
Content-Type: application/json;charset=UTF-8
Pragma: no-cache
Set-Cookie: accessToken=FycxgaSUgHnBlzMqYn/qsBEm5YBcmX52/eYbm+daUHPP1Fa7edawdawdawO1EdJlz9nyP5FrlPYnh/b//SZJRDs0Am8sGF+UZ+XffvPra8awdawd9+RbHiN0WcL+9T4xLlueMxd5bNVRVKHqeTonSK02Ym0cLxfALOeHrmbdqLS95uNOlzFYbjOuGV7bhwLGk5bavNPv9IWKqNAILAbkkw+gdawdawduM+BXdGE7KFbUgxvGmDw==; Path=/; Domain=subdomain.domain.de; Max-Age=PT448343981H30M29S; Expires=Sat, 16 Apr 2072 22:57:46 GMT; Secure; HttpOnly;SameSite=Lax
Set-Cookie: refreshToken=FycxgaSUgHnBlzMqYn/qsBEm5YBawdawdadawdupnO1EdJlz9nyP5FrlPYnh/b//SZJRDs0Am8sGF+UZ+XffvPra84jWTk9+RbHiM1+aNElVA8jXewqlexh7tGKuawdawdv4pxzC/RsDoGS/Jc8Xkzg133dYMCr7mRHlkU7jijoJrPYUAayiewVIMPUh/IE8sGUqIMKbiGoqAJAawdawdawdawdawdaw03GS4XgbwFj76V2AAAw==; Path=/; Domain=subdomain.domain.de; Max-Age=PT450502981H30M31S; Expires=Fri, 15 Jul 2072 21:57:46 GMT; Secure; HttpOnly;SameSite=Lax
X-XSS-Protection: 1; mode=block
Expires: 0
Transfer-Encoding: Identity
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Date: Mon, 22 Feb 2021 22:58:53 GMT
Access-Control-Allow-Credentials: true
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Vary: Origin, Access-Control-Request-Method, Access-Control-Request-Headers
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
Request data
MIME-Typ: application/json
Codierung: utf-8
Anfragedaten:
I also see, the cookie in the response:
But the cookies are not saved in the browser. This is a first party cookie which I am creating in my spring backend.
In Spring Boot, I create the cookies like this:
import org.springframework.http.HttpCookie;
import org.springframework.http.ResponseCookie;
#Component
public class CookieUtil {
public HttpCookie createAccessTokenCookie(String token, Long duration) {
return ResponseCookie.from("accessToken", token).maxAge(duration).httpOnly(true).path("/").build();
}
public HttpCookie createRefreshTokenCookie(String token, Long duration) {
return ResponseCookie.from("refreshToken", token).maxAge(duration).httpOnly(true).path("/").build();
}
}
There are a great number of problems related with Safari and the use of cookies, if you look up for information related with the problem you will find multiples bugs and solutions, ones appropriate for some cases, and ones for another.
Although Lax is preferable (please, see this great article), one thing you can try is setting your cookies SameSite attribute to None. Be aware that this change maybe could be relevant and affect the application behavior in other browsers, especially Chrome.
Another thing you can try is setting the domain for the cookie to something like .domain.de or domain.de to avoid any possible subdomain related problem.
Finally, please, pay attention to the fact that in your screenshot it seems that the value for max age is not printed correctly. Probably not but perhaps a similar issue, for the same version of Safari you indicated, has been reported here on SO in this question: the OP solve the problem by adjusting the value of the max age cookie attribute. Please, try different values for that information, maybe it works.
According to your comments, for future reference, in some way the problem seems related actually with the cookie max age: removing max age value from the cookie looks like a temporary workaround for the problem.
In safari you ll have to ask the user to allow the use of your cookie.
As of ITP 2.1, Safari uses its machine-learning magic to identify which first-party cookies can be used for tracking. Then, it blocks cookies unless you use the Storage Access API to ask users to allow the use of your cookie.
you can further read on how to use this here https://developer.mozilla.org/en-US/docs/Web/API/Document/requestStorageAccess

Permanent Cookie Contains Sensitive Session Information Laravel using Appscan security tool

I have scan the Laravel Project using AppScan tool, I am facing security issue Permanent Cookie Contains Sensitive Session Information issue in AppScan Security Document.
Here is My Network information of Header:
Cache-Control: no-cache, private
Connection: keep-alive
Content-Encoding: gzip
Content-Length: 3692
Content-Type: text/html; charset=UTF-8
Date: Thu, 16 Aug 2018 06:01:02 GMT
Expires: 0
Pragma: no-cache
Server: Apache
Set-Cookie: XSRF-TOKEN=eyJpdiI6Ik9XVzJyOXRSZ0JkRnhaTXdkZlQzeVE9PSIsInZhbHVlIjoibUxEKzBLUHdCM2VwWVc4MzhPNjR3TmpcL2VZdWJXRjJmeVZklSaGtnb2RRblVBblpXNEVDS1wvMXExKzQwaE9NWlQwVFRpUTZiTHB3b1ZRMlcwZz09IiwibWFjIjoiNzhmMDg4MjUzN2YzMDA3MDg3MTJiOGNkMTQ4MTZlNWIyZWZiZTkxYjgwNzI1NzVmMzBmNWQyYjE1ZThjZDc3MiJ9; expires=Thu, 16-Aug-2018 08:01:02 GMT; Max-Age=7200; path=/; secure;HttpOnly;HttpOnly;Secure
Set-Cookie: laravel_session=eyJpdiI6InJpK3FNeHhTMGFEUUgxSGxKUkc1Rmc9PSIsInZhbHVlIjoieVRGaGpMcnJ3bnBrWCtOTzZcL2dzVFRKNDl5U29jUTlvb0tSZE54d2YxbTFvSHZ3TW5jc2FXcFwvcjhLaXlFN2R5eEo0Tlpoa1FxY0VUWlJ5bUjIjoiYTY2MjkwODU3YWQyMTFmZTJkNmZlMWUzMTgyYzk2NjA2OTBiMDgyODMzM2ZlZjg4NDE4MDBjZDFkYmIyNmEyMCJ9; expires=Thu, 16-Aug-2018 08:01:02 GMT; Max-Age=7200; path=/; secure; httponly;HttpOnly;HttpOnly;Secure
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Vary: Accept-Encoding
X-Content-Security-Policy: allow 'self';
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Also When i stop/ remove cookies from server side. I will block the csrf token.
How can i fix this security issue.?
Please Help!!
Thanks in Advance
I think it's a bug in the AppScan application. The message is already correct, session information is stored in the cookie. This serves to transfer this token with every request and to send back a new CSRF token afterwards.
Since the cookie has a Max-Age=7200; the cookie lives only 2 hours. Therefore, AppScan's statement that the cookie exists permanently is false.
And remember, with each request a new CSRF-Token is assigned to you, whereby the attacker would have to manipulate your locally sent request to be able to use this method.

Decoding Ajax Response in WebKit browser is having issue

Issue:
We were having issue with one of the ajax request in webkit browsers ( Chrome, Firefox, and Safari).
scenarios working:
1. If we configure chrome/firefox with Fiddler and enable https decryption in fiddler it works as expected.
2. Works properly in internet explorer.
We were able to see response on page, but if you go to networking tab and check response it's null and request is not complete it's spinning. we were thinking it's more of webkit browser decoding issue.
Please share if you have any idea how to fix or what might be causing this issue, any input will be appreciated.
Raw HTTP Header
HTTP/1.1 200 OK
content-encoding: gzip
content-language: en-US
content-type: application/json;charset=UTF-8
date: Wed, 19 Aug 2015 18:38:23 GMT
p3p: CP="NON CUR OTPi OUR NOR UNI"
vary: X-Forwarded-Host
transfer-encoding: chunked
server-name: app2
cache-control: private, must-revalidate, max-age: 0
x-powered-by: Servlet/3.0
x-ua-compatible: IE=edge
strict-transport-security: max-age=31536000; includeSubDomains; preload
x-frame-options: SAMEORIGIN
expires: -1
The issue was server side, i was getting extra data in JSON response and data binding was not happening properly in chrome, firefox and safari.
Whereas IE is having loose binding policy i guess that's reason it was working in IE

Resources