In my application, user management is done through Keycloak. While testing my application end-to-end through Cypress, I came across an issue. When I sign up a user, it gives the following error:
We're sorry. An error has occurred, please login again through your application.
Cypress is adding something to a generated URL after I click the submit button, which is causing this issue. The same scenario tested through Protractor ran fine. I have noticed Cypress is appending session_code to the request URL. While doing manual testing, I don't get session_code.
Below is the URL generated through Cypress:
.../login-actions/registration?session_code=LsZbmsVVLwEH9s-xwFJ2JdDtaCu1_xzqAGOQCpjxGJI&execution=06fac3bb-fb19-474b-8659-2572586ae371&client_id=web_app&tab_id=PSlmfgdv0ls
Where as a manually generated URL is like following:
.../login-actions/registration?client_id=web_app&tab_id=PSlmfgdv0ls
My application backend is Spring Boot and the front-end is in React and Next.js.
It would be really helpful if anyone could guide us through this issue. Please let me know if you need more information about our application.
The Keycloak Authenticator documentation explains that the authenticate method checks the current HTTP request to determine if authentication requirements have been satisfied, and, if not, a challenge response is sent back. If the challenge response itself is authentication, then you'll see a URL with the session_code parameter.
It goes on to say that session_code, in the first URL example, pertains to the code generated from AuthenticationFlowContext.generateAccessCode(), which further explains:
String generateAccessCode()
Generates access code and updates clientsession timestamp. Access codes must be included in form action callbacks as a query parameter.
However, the "manually" generated URL, that does not include the session_code parameter, seems to indicate that the initial registration of the client has been successful and a client configuration endpoint is being used to make a GET request - a client read request - and all is well. Everything works fine.
Therefore, it seems that Cypress is being sent a challenge response (and potentially exposing a security flaw in your application). Possible reasons for this might be further explained within Cypress's documentation on Web Security.
Common Workarounds might provide you with a remedy, or, if all else fails, you might try Disabling Web Security for testing purposes as well.
Related
I downloaded the Azure AD with spring boot from https://github.com/microsoft/azure-spring-boot. Its all nice and works well as long as I run theazure-active-directory-spring-boot-sample using
mvn spring-boot:run
as shown in the README file.
I am trying just a basic real-life scenario where the angular/react app is running separately on a separate port using npm. The moment I separated them out the main Filter AADAuthenticationFilter is only invoked once on the first request where it does token verification and never again for subsequent requests.
I went around and configured an nginx proxy so that the domains of these two are now same
localhost:9999 and I redirect based on the next path like web for the npm and app for the Spring boot. This enabled the cookies to be available at every request.
This helps because what I learned is that Spring uses cookies to maintain a session. But ideally, the AAD filter should revalidate the token every request.
But if I add a property of azure.activedirectory.session-stateless=true to my application.properties, as mentioned in the filter's code to make it stateless and validate on every request. It expects roles as a different attribute in AD instead of it being a group of the user.
I also don't understand get the behaviour, when the js files are embedded within the spring app and run all this works perfectly fine and the filter is invoked at every request. But when I separate them out it just doesn't work.
Any help or pointers would be appreciated.
I realize that a lot more info may be required for someone to debug the above problem. But I was just able to solve this - at least found the problem that was causing it. Like I mentioned earlier the problem started when I separated the client and spring APIs. And since the client was not able to send back the cookies set by server, due to change in domains I had to put a proxy server.
What I found out later was that every GET request was always invoking the AAD filter. Even multiple requests. But other requests like POST, PUT were failing. I tried disabling the csrf config in spring WebSecurityConfig.java -->> http.csrf().disable();
This solved my problem and now I receive a request and all works as expected. Now I am trying to figure out how not to disable csrf completely.
Thanks
I'm learning Web services. I have created an Rest API on local machine in eclipse. And the url looks like this http://localhost.com/Web/Test/Client
What It does is when I call this url as POST method with username and parameters in url's body, I get one token which I'm using somewhere else. Upto here its working fine. I pass username and password and I get a token once my API's code verifies the credentials coming in url's body.
So after that I read about security of Rest API so that no body could access my credentials which are coming with url. It says it needs to be converted into HTTPS from HTTP.
But I could not understand more how and where this security needs to be configured in my code. Do I need to write any code to achieve this or any settings are required ? I'm totally blank here.
Can anyone please help me to understand this and tell me what needs to be done to get HTTPS for my url ?
What you need to do here is create a self signed certificate and configure channel security. I highly recommend you to use spring security framework to get this thing done. This article will help you.
To require HTTPS for the login page modify your security configuration by adding the following:
http.requiresChannel()
.antMatchers("/login*").requiresSecure();
I need to use Blackboard Web Services and I don't know how to establish a connection throught SOAP. I need something like Security Header. I read a lot, but always when I try to connect I get this kind of error.
I have a little big problem with this exception. Nothing is clear for me. I have nothing at the application log. I cannnot guess what should be the problem. I read also about AXIS2, Timestamps...
2016-03-08 20:53:58,739 ERROR edu.ku.it.si.registerproxytool.controller.RegisterToolController.registerProxyToolWithBlackboard:84 - There was an error in registering the tool: WSDoAllReceiver: Incoming message does not contain required Security header
Process finished with exit code 0
I'm looking to connect with a Blackboard web service through SOAP, and I can not send a correct Security Header
I read a lot about it, and finally I found this article. I'm using the project this guy post in the pdf. I have a Blackboard instance working at localhost on port 9876. I can do everything I want with it. It works fully.
I also tried to use SOAPui and I'm reaching a different error:
WSDoAllReceiver: security processing failed (actions mismatch)
I don't want to read more, I read more than 150 articles about it, and nothing.
Thanks :)
I have just started playing around with Blackboard web services, at the moment I am just accessing using SOAPui.
I am able to connect and send various functions, along the way I experienced the same error via SOAPui as you and so I found your question.
I overcame this error by doing the following:
Create a session using ContextWS.initialize, the username should be 'session' and the password 'nosession'. If successful this should return a token string.
Login using ContextWS.login. The username in the header should be 'session' and the password should be the token returned in 1. The userid and password in the body should be those of a user with sufficient web services permissions. If successful this should return 'true'.
Call whichever WS functions you wish. Always send the 'session' and token username and password in the header.
I found this here:
https://community.blackboard.com/docs/DOC-1116
I also found https://community.blackboard.com/thread/2147 and the linked youtube video useful to understand how to send the data correctly using SOAPui - you may need to change the wsdl url to https as SOAPui reverts it to a standard http. You also need to add a timestamp for every call.
I'm very new to web security and I'm trying to implement CSRF Gaurd on my web application.
I have done all the required configuration on my web application and I can see that token (FWJY-N767-M4HG-DHXT-WCE4-5J08-MV4G-LNV4) is getting generated/injected when I do a ajax call or when a html page loads. I have notice that token is same on every request.
However, I'm not able to validate token at server side. According to my research it should go to CsrfGuardFilter.java class and validate the token but when I'm debugging I can see that it is not going to CsrfGuardFilter.java class and it not validating the request based on token. I'm getting the response for the requests which doesn't contain token also.
Can someone guide me to implement CSRF Guard properly on my web application. Thanks for your help.
In my web application I'm using GWT to generate front-end JavaScript after doing bit of research on various forum I have figured out that because of GWT generated JavaScript code token was not getting injected into any ajax call. So to implement CSRF guard over GWT code I need to inject the csrf guard script before the *.nocache.js script.
Helpful link
you have to declare CsrfGuardFilter, CsrfGuardServletContextListener and CsrfGuardHttpSessionListener in your web.xml in the correct location. In my application, I placed it after the session was created. Also, you have to define mapping for JavaScriptServlet.
NOTE : I used owasp csrfguard 3.1.0 in my application and I only had to define mappings for the above mentioned components. For older versions, you might have to define more properties/components.
I took help from the following example for my implementation :
https://github.com/aramrami/OWASP-CSRFGuard
I hope you got your issue resolved and my answer will help someone in future.
I'm hosting a REST web service in a Grails application, using Spring Security, i.e.:
#Secured(['IS_AUTHENTICATED_REMEMBERED'])
def save = {
println "Save Ride REST WebMethod called"
}
I'm calling it from an Android app. (Calling the unsecured service works just fine.)
To call the service, I'm manually building up a request (HttpUriRequest) and executing it with an HttpClient.
I'm wondering what the best practices are, and how to implement them... Specifically, should I:
Perform a login once, to retrieve a JSESSION_ID, then add a header containing it into the HttpUriRequest for each subsequent request?
Or (not sure how I would even do this) include the login and password directly on each request, foregoing the cookie/server-side session
I think I can get option 1 working, but am not sure if Spring Security permits (2), if that's the way to go... Thanks!
--also, there isn't any library I'm missing that would do all this for me is there? :)
Spring security does support both basic authentication and form based authentication (embedding the username/password in the URL).
A REST service is generally authenticated on each and every request, not normally by a session. The default spring security authentication (assuming you're on 3.x) should look for basic authentication parameters or form parameters (j_username and j_password) (in the form http://you.com/rest_service?j_username=xyz&j_password=abc).
Manually tacking the j_username/j_password onto the URL, adding them as post parameters (I believe), or setting the basic authentication username/password should all work to authenticate a REST service against the default Spring Security interceptors, right out of the box.
I will admit that I haven't tried this on REST services, though I do clearly recall reading exactly this in the docs as I did the same for basic page logins on spring security recently. Disclaimer over.
I think you can use a login-once-and-get-a-token method that's similar to how oauth works.
sending username and password across the network outside of secured channel(https/ssl) is a terrible idea. anyone on the network can sniff your request package and see the clear text password.
on the other hand, if you use a token method, since the token string is randomly generated, even the token is compromised, the worst case is someone can use the token accessing your REST API.
another solution is going through ssl tunnel(HTTPS). i have actually done a comparison and result shows: 80 requests/min(https) vs 300 requests/min(http)