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

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

Related

How to Capture the API's ?if API's have no end points and just showing baseUrls

I need help or any suggestion. I have no idea how to do it?
Request URL: https://www.vizofly.com/NTU/Stress/StreamingAssets/Schools.json
Request Method: GET
Status Code: 200 (from disk cache)
Remote Address: 172.66.43.59:443
Referrer Policy: strict-origin-when-cross-origin
alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400
cf-cache-status: DYNAMIC
cf-ray: 6d4c32aacdb1926d-FRA
content-encoding: br
content-type: application/json
date: Fri, 28 Jan 2022 18:14:00 GMT
etag: W/"1261-61f2caaf-3e2d8e;;;"
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
last-modified: Thu, 27 Jan 2022 16:39:11 GMT
nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
report-to: {"endpoints":[{"url":"https://a.nel.cloudflare.com/report/v3?s=aVZAHndifoZtrY0MH3O1WlauF71saxbdUuS7eBS0tReoUi5fGDG3zSlxFCTvbIwJxvGeVeiQyjT%2FVIUWKfUpxNbRT1jUi%2F9VEOvJnaBBRtJKapsW8RBKeLUxqP%2FusLzYEHQ%3D"}],"group":"cf-nel","max_age":604800}
server: cloudflare
x-content-type-options: nosniff
x-frame-options: ALLOW-FROM https://www.ntu.edu.sg
If you're asking about how to configure JMeter to send the request:
Add Thread Group to your Test plan
Add HTTP Request sampler and set it up like:
You may also want to add HTTP Cache Manager to represent browser cache, HTTP Cookie Manager to automatically handle cookies and so on in order to configure JMeter to behave more like a real browser

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)

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

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.

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.

Should I disable WebClient caching?

WebClient.DownloadStringAsync does cache the server response.
After once getting a response from the server I get a response even without internet connection!
Is WebClient caching smart enough to determine from the server response how long to cache?
Or is it buggy and I should disable caching.
Backgound info:
Url: http://www.ecb.europa.eu/stats/eurofxref/eurofxref-daily.xml
Fiddler trace:
GET /stats/eurofxref/eurofxref-daily.xml HTTP/1.1
Accept: /
Referer: file:///Applications/Install/4D0DF1F7-1481-45CA-86BE-C14FF5CCD955/Install/
Accept-Encoding: identity
User-Agent: NativeHost
Host: www.ecb.europa.eu
Connection: Keep-Alive
HTTP/1.1 200 OK
Date: Sun, 25 Mar 2012 08:54:40 GMT
Server: Apache/2.2.3 (Linux/SUSE)
Last-Modified: Fri, 23 Mar 2012 13:31:39 GMT
ETag: "19d4e5-6a9-4bbe90b5904c0"
Accept-Ranges: bytes
Content-Length: 1705
Keep-Alive: timeout=3, max=200
Connection: Keep-Alive
Content-Type: text/xml
Set-Cookie: BIGipServerPOOL.www.ecb.europa.eu_HTTP=2684883628.16415.0000; path=/
...
Disabling caching via Headers does not work:
.Headers("cache-control") = "no-cache"
.Headers("HttpRequestHeader.IfModifiedSince") = DateTime.UtcNow.ToString()
Disabling caching via appending uniqa parameter works:
"http://www.ecb.europa.eu/stats/eurofxref/eurofxref-daily.xml" & "?MakeRequestUnique=" & Environment.TickCount
The integrated cache isn't smart at all. So if you expect different results when querying the page, you have to bypass it. I say 'bypass' because there's no way I know of to disable it with the WebClient (I don't think it's enabled if you directly use the HttpRequest class).
So if you want to use the WebClient, the best way is to append a random parameter to the request.

Resources