We are using WebSphere Liberty Profile (17.0.0.4) to run our JAX-RS REST services. We are running our applications through Contrast, which is a scanning service. It is flagging our cookies as having the secure flag turned off. However, we are not using or touching any cookies in our code. The only cookie that is coming back in the response from our services is LtpaToken2, and sure enough, it has the secure flag set to false. How can I enable the secure flag for the LtpaToken2 cookie (hopefully via configuration and not having to read and rewrite it in our code)?
Adding <webAppSecurity ssoRequiresSSL="true"/> to the server.xml file should do it.
Related
0
I have issues running scripts that work fine on my laptop but not on Server VMs (Both Windows and Linux).
Some of the modules on the application I test communicates with the client through Cookies. bearer authentication token is expected to be sent with the request header as cookie when accessing these functionalities. These are mostly javascript events on the browser.
JMeter 5.3 on my laptop is successfully sending these cookie values with / in server name field to the application server and also get the successful HTML response. But on the Linux/Windows server, it gives illegal character error (rightly so).
I then decided to develop the scripts directly on Windows Server. When I remove and added / in the path instead of the host name, the cookie value (token) was not sent and the application server throws authentication error. If I add 2 forward slashes, it works for some endpoints it works with 3 forward slashes. ///. Some endpoints works with // and if you choose "Redirect Automatically" only. If you choose "Follow Redirects", the application again throws authentication error. The developers are blaming JMeter for incorrect request but are not giving me more information.
Also tried setting the CookieManager.save.cookies=true in jmeter.properties
Can someone please help with this weird JMeter behavior?
Thanks,
Partha
If you're talking about "Domain" field of the HTTP Cookie Manager:
then you can tell your developers that they should stop blaming JMeter for sending incorrect requests but they should rather read RFC 6265 followed by RFC 1034, once done they should quit their developer jobs and become rickshaws.
If you want to know more how does JMeter handle cookies the best way is enabling debug logging for the HTTP Cookie Manager by adding the next line to log4j2.xml file:
<Logger name="org.apache.jmeter.protocol.http.control" level="debug" />
and next time you start JMeter you will see way more information regarding cookies extraction and manipulation in the jmeter.log file.
I'm currently working on a React project. The development server (Bottle/Python) for the project is hosted remotely, and my React dev-server is localhost. Part of the authentication process for the application involves setting a cookie on login, but because of same-site and secure rules that cookie is not being set, meaning that my dev frontend can't access any of the data that it needs.
Myself and the server engineer have added SameSite=None to the cookie as well as secure, but because my localhost is not https the cookie is still not being stored properly (I get the error message "this Set-Cookie" was blocked because it had the "Secure" attribute but was not received over a secure connection").
There are no issues when the app is deployed because everything is on the same domain, but for now we're stuck - we've been trying to solve the issue for several hours but can't seem to get it.
My question is - what is the best development practice if you need to access a non-local development server, but can't actually just have your own version of the server running on your local machine?
Do I:
Need to make my localhost https somehow?
Need to make the dev-server domain https?
Need to install the server locally because there's just no way to do this?
Apologies if this is a noob question, it would be great to have some advice.
Many thanks.
The short answer is:
No
Yes
No
You can run your app on http://localhost:port. Assuming response from your dev server has in response headers Set-Cookie of the cookie which has Secure flag, your dev server URL has to be https in order to have the cookie accepted by the browser.
I have this setup and it works just well.
Regarding CORS (as mentioned in the title of the question): you have to have you server configured to accept credentials and to have allowed origins configured. The client app when doing XHR request has to have withCredentials:true. Check the points 2 and 3 in my post for details.
Also note, that if you are using Chrome you can bypass for development purposes the requirement to have SameSite=None and Secure by disabling the flag "Cookies without SameSite must be secure", also detailed here
We're trying to set up a load balancer with HAProxy which will serve multiple backend web applications. The use case is something like this:
User browses to foo.com/app1
HAProxy sees that the cookie doesn't contain session information, and redirects to an authentication gateway (a single-sign-on page of sorts)
The auth gateway provides a form, where if the user successfully logs in, the gateway redirects back to HAProxy, with a COOKIE storing the session details
HAProxy now sees that valid session information is present and redirects to app1-internal.foo.com (the actual web application) with the same COOKIE - which is used further by the web application.
Our doubt is in the 3rd step. We would like to encrypt the cookie which the authentication gateway adds (via AES or similar). The problem is, that at the HAProxy end we can't seem to figure out how to decrypt it, since HAProxy doesn't seem to support decrypting headers (or even running an external C/C++ program that can decrypt it). So our questions are:
Can we decrypt AES encrypted headers at HAProxy itself (note that this is not an SSL connection) ?
Is HAProxy not really designed for this use case - is there a better tool for this purpose that you can suggest for us?
Many thanks in advance!
I'm setting these cookies for a single sign on solution where I have one app running at foo.example.com and a different app running at bar.example.com.
I know that I can set a cookie from foo.example.com for .example.com.
If I had control over bar.example.com I'd just have it recognize a cookie from .example.com. But I have very little control of it.
For what it's worth, the app at foo.example.com is in python and the app at bar.example.com is java.
You can certianly try. However, browsers should not honor this behavior as it is a cross-site cooking attack.
This is not possible. SSO is done using protocols such as OAuth or SAML that imply sending signed messages between the endpoints and/or communication between them. There is no way to do this on the "client side".
I have implemented secured login and signup in my website.It working.Now I want to test it.I am not sure how to test whether it is correctly secured.
If you want to test whether it breaks when used with SSL, you could easily test drive it by downloading and installing OpenSSL, follow this tutorial to create a self-signed certificate with OpenSSL, install your newly created certificate on your web server (Apache, if you are using LAMP or XAMPP) and finally restart your web server. Now you have SSL ready to be used, try to use your login form via https:// and see what happens. If a web browser like Firefox complains about your certificate, tell it to create an exception.
That is how you can test it over SSL, but as for the "whether it is correctly secured", things get harder. Make sure you have at least taken care of:
Session fixation
Cross-site scripting
Secure password storage (hashing)
SQL injections
Protecting against brute forcing with throttling or using CAPTCHAs
This depends what the website is made of, for instance if it's using Apache or if it's an home-grown server.
Verify the site is only accessible via HTTPS (if this is what is wanted)
Test an access via HTTP - verify behavior is as expected (could be redirection to HTTPS, error page or warning message ...)
Try to access the site without going thru the login page (i.e. forging URL)
Open a session, try to access it from another client without logging in.
Test for "obvious" passwords (test/test, admin/admin)
Verify you cannot login without empty username/password
Verify one cannot access the private key of the system
Verify one cannot access all files of the system (eg http://website.address/../../../../etc/passwd)
...
You can also use a website security test suite, see this list by insecure.org, there are commercial products and free/open source tools.
IMHO, you should not try to test SSL, as this is a third-party tool.