I have a use case that goes like this:
1- A user logs-in to a FIRST server (via a web form of some sort).
2- This FIRST server establishes the user connection.
3- The FIRST server sends a URL redirection to the user.
4- The user's browser will point to SECOND server.
This is where it's not clear if what's in my head is actually feasible.
Can the browser redirection send a payload in a HTTP POST/GET to the redirected URL? Let's say:
5- SECOND server recieves POST in servlet to process the payload
public void doPost(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
...
}
What is actually going on, is I have 2 servers. FIRST establishes the connections and sends back a token (with security assessment, user info, and stuff). This token needs to be forwarded somehow to SECOND which will parse this token (an XML stream) to get to "know" the user.
I'm I completly insane?
Thx.
It depends which kind of redirect you are doing. If you just use a "location" header, you will only be able to pass a GET payload.
Now, in order to send more data you need to write a temporary page (that may be blank) with a <Form> (that may be hidden) that point to the 2nd server and that will auto submit itself automatically (using Javascript for instance). The said form will be able to POST any data to the 2nd server.
Please consider the security issues while sending tokens from one server to another and make sure people can't guess or copy those tokens, or that the two servers communicate through another way to make sure all clients are legit.
Related
I've been doing some HTTP methods and header research recently if we should use GET with basic authorization instead of POST when submitting?
HTTP Methods
The GET method requests a representation of the specified resource. Requests using GET should only retrieve data.
The POST method submits an entity to the specified resource, often causing a change in state or side effects on the server.
As we see here, the POST method normally changes the state of the server. If sending out JWTs/HTTP cookies, we are not modifying the state of the server. Nor are we creating a new resource in the server.
I understand that we should not not send the username and password as a GET parameter but should we use the authorization header instead?
Basic authentication
For "Basic" authentication the credentials are constructed by first combining the username and the password with a colon (aladdin:opensesame), and then by encoding the resulting string in base64 (YWxhZGRpbjpvcGVuc2VzYW1l).
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
The only advantage I see to using POST over GET is that we need no extra code in the HTML/JS on the client side to send headers via the fetch API. To send headers, we would need an onsubmit and then check if status code is 200. If 200, we will need to redirect to the page after the login screen. Then again, if using the fetch API, this means the server does not need to send a new HTML page to the client all the time either.
Should we use GET with basic auth or POST when logging in since we don't create a resource/modify the server state?
Would this change if say we enable 2FA since we would need to generate a code for that user?
Doing basic authentication in the browser and using GET is not that recommended.
To do your own login form it is better to always do it using HTTPS and POST. Do post the username/password in the body of the request and secure it with proper CSRF protection.
If you want to level up, you can always look at the OpenIDConnect approach, but that is more advanced depending on your needs.
Also, a good approach is to explore how existing site implement a login form and look at the HTTP(s) traffic in a tool like Fiddler.
I have a case with an Order System (ASP.NET Core 2.2 with Identity Server 4 auth)
where I post form-data to an external Api from a Controller for Payment purposes.
The remote Api is configured with a return-url (after Payment is processed)
Problem is when the user is returned to my system they are no longer authenticated so they are automatically redirected to the identity-server and automatically re-autheticated (as the Cookie is still valid) but in this process the returned data from the api is lost. I can see the data (and the complete request) in my logs, but the Controller-method for the return-url is never accessed (as before that point the middleware has detected the user is not authenticated, or this is my assumption.)
If I cannot capture the returned data I cannot save the results from the Payment attempt.
(For testing purposes I have set [AllowAnonymous] attribute on the return-url controller method, but this did not work. It still redirected to the identity-server.)
How does one solve this as I cannot handle this in the controller method as this is never accessed ?
(The remote Api does allow for custom parameters to be passed and then returned as query-strings to the return-url.)
Thanks
//Jonas
[Edit] : The response is posting some user-data like address etc to the web-service (it is not a rest API, sorry for mixing words). The user then gets a HTML response from the remote webservice with a form to post the creditcard info. At this point they are no longer on our site, after post they are redirected to the return-url on our site. This is where they are no longer authenticated, but I assume they still have the cookie, as they are automatcally logged in without needing to input username and passw again. (so I guess in a sense they are still authenticated, but the system is not able to get the user info. User info is filled again after re-route to the identity server and back.)
I am a beginner in security and reading about the host header injection. I tested an application for this vulnerability and it is possible there for some request but developer implemented no-cache, no-store flags and this vulnerability is not in password reset request.
So first thing is there will not be cache poisoning. and the second is it is not happening in password reset request.
As I understand that for exploiting this vulnerability, I changed that host header. So I want to know why will It be a vulnerability, why a user will change Host of the application? and how an attacker can exploit it?
As in all of the cases the client input on the application should be never trusted (in security terms). The host header attribute is also something that can be changed by the client.
A typical attack scenario would be for example:
Lets suppose you have an application that you blindly trust the HOST header value and use it in the application without validating it.
So you may have the following code in your application, where you load a JS file dynamically (by host name):
<script src="http://<?php echo $_SERVER['HOST'] ?>/script.js">
In this scenario, whatever the attacker set as the HOST header would be reflected on this JS script load. So the attacker could tamper with this by manipulating the response to load a JS script from another host (potentially malicious). If the application is using any Caching mechanism or CDN and if this request is repeated multiple times, it can be cached by the Caching Proxy. Then, this can be served to other users as well (as it was saved to cache).
Another way of exploiting this is:
Let suppose that the application has a user password reset feature. And the application will send an email to whoever asks for a password reset with a unique token to reset it, like the email below:
Hi user,
Here is your reset link
http://<?php echo $_SERVER['HOST'] ?>/reset-password?token=<?php echo $token ?>
Now an attacker can trigger a password reset for a known victim email by tampering the HOST header value to the one of his desire. Then the victim would receive the legitimate email for password reset, yet the URL will be changed to the domain set by the attacker. If the victim would open that link, the password reset token could be leaked to the attacker so it would lead to account takeover.
Say the page where user can update his own profile: profile_update.php?id=1234567...(user's Google id).
Question:
How can I restrict access with the returned authResult or me? (I mean which item in the object will help that, not how to get these item out).
or Do I still need to build a server side $_SESSION for that?
You could do some validation on the client side using the auth result, but you'd also want to verify that the request you get on the server side is from who you think it is from to prevent cross-site request forgery attacks. So you'd need something that validate that the POST that update the profile came from an authenticated user, not just that the POST data was in the correct format. So typically, your form will send a specific code (a CSRF token) and that same token must be present in the user's cookies (or a server side session token, which in PHP can be accessed via $_SESSION).
Is there a way using Java to over-ride the browser authentication dialog box when a 401 message is received from the web server? I want to know when this dialog is being displayed, and instead of it being given to the user, I fill in the credentials for them.
Overview of application:
i wrote the web server, so essentially i want to stop someone from opening an external browser and putting in the localhost and port to gain access to the data being displayed. my app has an embedded web browser linked to my written server. the browser displays decrypted content, so if i force the auth (even for my embedded browser), an external browser would need credentials. if my embedded browser is trying to access the files, i supply the credentials for the user and display the content
If you don't care about the password showing you can construct the URL so it passes the credentials ex. http://username:password#www.example.com This will by pass the authentication box but will show the user the credentials so also might not be what you are looking for.
SWT 3.5M6 has a new listener within it call AuthenticationListener. It simply listens for authentication event passed from the server and is fired. The code below is what performs the behavior I wanted. It waits for the auth, and if the host is my application, it passes back the credentials. Of course fill in the USER_NAME, PASSWORD and HOST_NAME with appropriate variables. Otherwise it lets the browser auth dialog pop up and makes the user enter the credentials. This code can also be found in the Eclipse SWT snippets page:
webBrowser.addAuthenticationListener(new AuthenticationListener()
{
public void authenticate(AuthenticationEvent event) {
try {
URL url = new URL(event.location);
if (url.getHost().equals(HOST_NAME))
{
event.user = USER_NAME;
event.password = PASSWORD;
}
else
{
/* do nothing, let default prompter run */
}
} catch (MalformedURLException e) {
/* should not happen, let default prompter run */
}
}
});
your question is a bit unclear. The whole basic authentication is based on HTTP Headers.
If the browser gets an authorization header than it displays the dialog. The content from the dialog is then send back to the server. There is nothing special about it. It iser username:password in base64 encoded. Have a look at
wikipedia
The problem is how you want to interfere. You would have to capture the authorization header and then for the next request you have to alter the HTTP header to include the credentials.
hope that helps
I think this is mostly browser-dependent behavior and what the server reports to the browser.
For example, Internet Explorer, being a Microsoft product, directly supports automatic sending of Windows credentials (you can modify this behavior in your Internet Settings) after an anonymous request fails in a 401.
Firefox, for example, does not and will always prompt the user even if it was set to remember the id and password via the password manager. IE will also prompt if auto-login fails (such as your Windows credentials still result in a 401 because you're id isn't allowed).
I don't think, as a web developer, you have much control over this besides setting up your server and app to work in the most expected and harmonious way... if you could, this might get into black hat territory.
If you want to control what is displayed to the user for authentication, you can change the auth-method in the login-config section of the web.xml from BASIC to FORM.
Then you can specify what page should be displayed when the user is authenticating, and, I suppose, pre-fill the credentials for them...but doesn't this defeat the whole purpose of security?
Setting up Authentication for Web Applications
Edit after further details:
My only suggestion would be to change the auth-method to CLIENT-CERT and require two-way SSL, where the client is also required to present a certificate to the server. If you install the certificate into your embedded browser (and make sure external browsers can't get the certificate) then you should be OK. And actually this should stop any authentication dialog from being displayed.