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.
Related
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)
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
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.
I have been trying to get a rather simple JMeter test up and running with cookies for days and having no luck at all. I have exhausted almost all SO threads with attempts to fix this, but no luck yet.
My test is simply to POST login username/password to a server, which returns a SAML token if successful. Then I resubmit that SAML token to my replying party site, which successfully responds with cookies in the headers.
However, every subsequent request does NOT pass along these cookies.
Here is the layout of my plan:
Thread Group
HTTP Request Default
HTTP Cookie Manager
HTTP Request - GET load login page
HTTP Request - POST user/pass to remote server and store SAML token
HTTP Request - POST Submit SAML token to Relying Party site (successfully returns cookies in response)
HTTP Request - GET View protected page (always send [no cookies])
Debug Sampler
View Results Tree
Aggregate Report
I Have enabled these settings:
CookieManager.allow_variable_cookies=true
CookieManager.save.cookies=true
CookieManager.check.cookies=false
The result of the 3rd HTTP Request Sampler responds with a HTTP Response like this:
Thread Name: Visitors 1-1
Sample Start: 2015-09-29 11:53:49 AEST
Load time: 1949
Connect Time: 400
Latency: 1369
Size in bytes: 83261
Headers size in bytes: 2013
Body size in bytes: 81248
Sample Count: 1
Error Count: 0
Response code: 200
Response message: OK
Response headers:
HTTP/1.1 200 OK
Cache-Control: no-cache, no-store
Content-Type: text/html; charset=utf-8
Expires: -1
Pragma: no-cache
Content-Length: 81248
Date: Tue, 29 Sep 2015 01:53:52 GMT
Connection: keep-alive
Set-Cookie: sitecore_device=; path=/
Set-Cookie: .ASPXAUTH=CC27DB52E62EA5412220CB33ECD9BB84F4A65B76C5A46F8A5A2271AC862C8ED4C71F06258060F30EEB162EF43863B5EDBCDAE0D07002AA71D64F5A473D6FF197E2598F1ACAACB6E36D64D5B9E3B59C102851FF9B22844079BCA09326D491FE5F763E5C7A03FE89AA000600E452B5EAAA64AB83ED5D870B18F86DD213A524FB2F2DF76FECDCB302DEB51BBF39F9FAE6308111E5E084009F1DD8A82E700D8C8DD04E7015DAFFEB5F7373210019F72DF323C3CF2D02; path=/; HttpOnly
Set-Cookie: ASP.NET_SessionId=1yguqfbt5eyrvgo1agawui0z; path=/; HttpOnly
Set-Cookie: sitecore_device=; path=/
Set-Cookie: .ASPXAUTH=CC27DB52E62EA5412220CB33ECD9BB84F4A65B76C5A46F8A5A2271AC862C8ED4C71F06258060F30EEB162EF43863B5EDBCDAE0D07002AA71D64F5A473D6FF197E2598F1ACAACB6E36D64D5B9E3B59C102851FF9B22844079BCA09326D491FE5F763E5C7A03FE89AA000600E452B5EAAA64AB83ED5D870B18F86DD213A524FB2F2DF76FECDCB302DEB51BBF39F9FAE6308111E5E084009F1DD8A82E700D8C8DD04E7015DAFFEB5F7373210019F72DF323C3CF2D02; path=/; HttpOnly
Set-Cookie: ASP.NET_SessionId=1yguqfbt5eyrvgo1agawui0z; path=/; HttpOnly
Set-Cookie: rvconf=0; path=/; HttpOnly
Set-Cookie: rvre=14432509917526119; path=/; HttpOnly
HTTPSampleResult fields:
ContentType: text/html; charset=utf-8
DataEncoding: utf-8
I also realise that some cookies are being set twice from the server, but this is out of my control. I hope that this is not the issue...
Pass the cookie variable in jMeter (you can access your ASP.NET_SessionId in this manner ${COOKIE_ASP.NET_SessionId}) to pass the cookie values to the HTTP Header Manager associated with the request.
JMeter Cookie Manager
We have a Magento application which is issuing dual Set-Cookie's . Here are the headers:
HTTP/1.1 200 OK
Date: Wed, 18 Apr 2012 21:04:28 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.2.10
Set-Cookie: frontend=iti6c00cdm6cc79hfl1pl9pq52; expires=Wed, 18-Apr-2012 22:04:28 GMT; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: frontend=iti6c00cdm6cc79hfl1pl9pq52; expires=Wed, 18-Apr-2012 22:04:28 GMT; path=/; domain=**example.com**
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
In some circumstances, after logging in the second cookie is set to frontend=deleted . From my reading it appears that two frontend= cookies are not a "problem", this is standard Magento behaviour. From my reading of the spec, the second frontend= cookie will overwrite the first if their scope/spec is the same.
Any ideas where we can start digging in to this problem to see why the second frontend= cookie does not behave like the first?
Magento version is enterprise edition of ver. 1.9.0.0
Related Questions
Why does Magento use 2 cookies per session?
Magento Cookies Changing Prevent Frontend Login
This happens when the Session validation checks fail - the cookie will then be cleared with the "deleted" value and a expiration date in the past:
The following information will be checked by Magento for validating a session:
The client IP address that is connecting to the server
The "Via" HTTP-Header
The "X-Forwarded-For" Header
The "User-Agent" Header
If one (or more) of these informations changes during the requests for the same Session ID, the session will be Discarted, the Cookie will be cleared in the way as described and the Server will send a Redirect header to the Homepage.
You can change which Information to validate in the Magento Admin-Panel by going to System > Configuration > Web. But you should never turn off all checks since this will allow session hijacking.
Do you want to override fronten cookie... if so better try to first destroy the cookie and then reset it by using Magento method
Mage::getModel('core/cookie')->set('frontend', $session->getCustomer()->getId(), 100000*24*3600);