The HttpUnit API for webclient says that "Will only send the authorization header when challenged for the specified realm." What does challenged mean in this case? How does HttpUnit recognize a challenge?
This refers to the way HTTP Authentication works:
When accessing a protected URL (for the first time, with no credentials included in the request), the server will send back a response that has a status code of 401 Unauthorized and a WWW-Authenticate header set to something like Basic realm="My Realm". This indicates that Basic authentication is needed for the given URL and the realm is named 'My Realm'. This is the challenge - the user agent is being informed by the server that the URL it tried to access requires authentication and it should send back the user credentials. The user agent will typically prompt the user for credentials and then retry the request, this time with a Authorization header set to something like Basic rXflcjMwYXxz where the second part is the Base64 encoded username and password pair.
In case of the HttpUnit method you've linked to, you'll see that it requires a realm, username and password. I imagine that when the a URL is accessed, if it gets back a 401 (the challenge) from the server, it'll compare the realm you passed it with the realm in the response; if it matches, it'll attempt to authenticate with the username and password supplied.
References:
RFC entry for 401
Headers for authentication
Basic access authentication
When the server responds with a 401 error, the HttpUnit throws an AuthorizationRequiredException. We can use getParameter("realm") of the exception to get the realm and send a request again with this realm name.
Related
I got a website to handle all security issues raised by a software during Pen Testing. Please refer to the following screen shot:
jquery.signalR-2.4.1 is being used in the project (ASP.NET MVC). I need to give explanation to the security team about the use of above URL, why it is showing under a GET request. Is there any threat for the application? If yes how to remove the connection string from the query string inside the URL? If it's an inbuilt process or method what's the exact use?
It's a connection token, not a session/security token. This is documented in Microsoft's SignalR security section of the documents. I would refer your security team to this information as they are not aware of the difference here and how it is used. Especially the bolded portion below:
Here it is in case the link changes -
SignalR's connection token isn't an authentication token. It is used to confirm that the user making this request is the same one that created the connection. The connection token is necessary because ASP.NET SignalR allows connections to move between servers. The token associates the connection with a particular user but doesn't assert the identity of the user making the request. For a SignalR request to be properly authenticated, it must have some other token that asserts the identity of the user, such as a cookie or bearer token. However, the connection token itself makes no claim that the request was made by that user, only that the connection ID contained within the token is associated with that user.
Since the connection token provides no authentication claim of its own, it isn't considered a "session" or "authentication" token. Taking a given user's connection token and replaying it in a request authenticated as a different user (or an unauthenticated request) will fail, because the user identity of the request and the identity stored in the token won't match.
I tried https://myserver.com/~username=username&password=mypassword but it doesn't work.
Can you confirm that it's possible to pass the user/pass via HTTPs parameters (GET or POST)?
Basically, I want to access this link https://www.globalnorm.net/gn/doc.php?name=ASTM%20F%202638:2012-00&erx=0 (but I need to authenticate ) How can pass my username and password in URL?
The standard method to pass basic authentication to web servers is to use a url of the form:
http://user:password#domain.com/
Web servers do not expect basic authentication in the query parameters. You can, of course, implement your own authentication using query parameters / HTTP headers or any other method.
Update
The specific URL you had supplied redirects to https://www.globalnorm.net/login.php?ecd=S&info=nosessionorcookie&doc=....
The login path does not return the header WWW-Authenticate which is used to indicate that basic authentication is supported. So no point in trying HTTP basic authentication.
This specific login page seems to expect a POST request to /login.php with USR, PAS parameters. The answer will probably include a cookie which is later used to authenticate with the server.
There seems to be some controversy about whether or not browsers have dropped the feature, and/or whether the feature is deprecated. But unless your browser has in fact dropped the feature, then as noted in #nimrodm's answer above, you can specify a url with basic authentication as
http://user:password#domain.com/
However, you really should not use http protocol, since that will send the credentials in clear text. Instead, just use:
https://user:password#domain.com/
Note that you must urlencode special characters in the user or password fields (I frequently use '#' in my passwords, so those must be written as '%40').
The browser extracts the credentials, and passes them to the server in an Authorization header:
Authorization: Basic credentials
where the credentials are simply the (url-decoded) string "username:password" as written in the url, but base64-encoded. But since the https connection is encrypted, the header is encrypted and the credentials are not exposed outside the browser.
I think the whole issue about removing support or deprecating the feature was based on the security implications of specifying the credentials using http protocol. But with the availability of free ssl certificates, and the push for "ssl everywhere", that no longer seems like much of a problem these days.
Of course there's also the issue of how much good passing credentials this way does you. Many or most applications that require login expect to get the credentials from a form the user fills out and sends with a POST request. The application would have to be written to check each request for an Authorization header, and if present, process the credentials the same way they would if they had been specified by a POST of a filled-out login form.
Applications that expect HTTP basic authentication generally are built with that requirement built into the server configuration, e.g. using Apache directives along theses lines:
<Directory "/htdocs/protected">
AuthName "Registered User"
AuthType Basic
AuthUserFile /lib/protected.users
require valid-user
</Directory>
Where the file /lib/protected.users is a file of encrypted usernames and passwords generated by the Apache utility program htpasswd. With this configuration, any request for resources below /htdocs/protected is automatically checked by Apache for an Authentication header. If the request has no such header, or the credentials specified in the header do not match one of the pairs of usernames and passwords in /lib/protected.users, then the server responds with a 401 Unauthorized status and a header:
WWW-Authenticate Basic realm="Registered User"
Note that the realm value "Registered User" is the AuthName value from the Apache configuration. The browser handles this response by displaying a prompt requesting username and password, with the value of the realm contained in the prompt to give the user a hint as to what particular username and password is required.
Browsers have to treat the credentials specially anyway to convert them to an Authorization header, and so they also cache them and send them each time with requests to the same endpoint, like sending cookies. If they didn't do this, then the user would have to supply them on each subsequent url specifying that endpoint to avoid getting prompted.
Hope this helps.
The web server doesn't care about anything past the "?". This data gets sent to the application.
If you're actually authenticating to the application you would need to check the app's documentation for the correct parameter names.
In the past, you could supply the username:password#domain in the URL, but this has been disabled in many recent browsers because of security risks.
Currently, the only way I'm aware of to do an auto login is to set a basic auth header and do a form post, however you'll be better off to use a library that already knows how to do it, since the fields need to be encoded properly to work.
If I am correct in my assessment, the question is Can you confirm that it's possible to pass the user/pass via HTTPs parameters (GET or POST)?
Here is a snippet of code that I am using to send username and password as parameters to a GET call. Hope it helps.
$('#button').click(function () {
var username = $('#username').val();
var password = $('#password').val();
window.location.href = '#Url.Action("DesiredAction")?username=' + username + '&password=' + password;
});
The image below depicts basic HTTP authentication. The client requests /family resource and it is asked to identify itself. It does and now it can access the /family. The client then also asks for /family/photos/kids resource which is in the family realm.
The client already identified itself for /family resource, but not also for /family/photos/kids. They are in the same realm, but the server doesn't know that the same client issued a request. Or does it? How does the server know that this particular client is also allowed to access /family/photos/kids on subsequent request? Is the password and username send on every request after the user has authenticated? Is the client asked for via pop-up for every request he/she makes? Are cookies set upon first authentication?
Basic authentication requires a header sent by client. No cookies or server session
When the client requests a resource, sends the Authorization header
GET /family
Authorization: Basic token
Where token is base64(username: password). Username followed by ':' and password encoded in base 64
If you are requesting a protected resourced from your browser for example a GET request, and you do not provide the header, the browser shows the autenticathion form and remember it for subsequent requests in the same domain
Let me quote HTTP 1.1 RFC specification from www.w3.org.
10.4.2 401 Unauthorized
The request requires user authentication. The response MUST include a
WWW-Authenticate header field (section 14.47) containing a challenge
applicable to the requested resource. The client MAY repeat the
request with a suitable Authorization header field (section 14.8).
14.8 Authorization
A user agent that wishes to authenticate itself with a server usually, but not necessarily, after receiving a 401
response does so by including an Authorization request-header field
with the request. The Authorization field value consists of
credentials containing the authentication information of the user
agent for the realm of the resource being requested.
Why the credentials intended to prove user identity (Authentication) passed in Authorization header?
You can see it like this. The server says to the client "Please authenticate before accessing this resource" and sends information on how the client should do the authentication (WWW-Authenticate). The client is responsible for authenticating and then sends proof of that authentication to the server (Authorization).
The Basic authentication scheme messes things up because the authorization is a username and password, that is, you authorize by authenticating against the server itself (showing you know a user and password).
Nevertheless other schemes allow the client to authenticate with a third-party and only send a proof of the authentication to the server. The server can verify the authorization and may not know who the client is (although it typically does).
Note This is only a rationalization. I don't mean to say this was the motive behind the chosen names.
One possibility is that it is talking about the authorization from the user's perspective, not the server's.
There are actually two authorizations going on:
The user authorizing the client to act on their behalf.
The server authorizing the user to access its resources.
If we assume the header is named after 1) then we have:
The user authorized the client to act on their behalf. That authorization goes in the Authorization header. The server then used the user's authorization of the client to authenticate the user (confirm the client is acting on behalf of the user). Now it knows who the user is, it will then do its own separate checks for 2), to see if the user is authorized to perform the request.
Which status code would you use in this scenario, assuming you're using a token based authentication:
The client has a token and makes a request to the server.
The token expired and the server sends a 401 Unauthorized.
The client sends the refresh token.
The token is invalid and the server responds with XXX?
The use case would be an application, that automatically catches 401's and makes a request with the refresh token. If the server would respond with a 401 if this token is not valid, the client would try to request a new access token with the refresh token forever. But it should tell the client, that it should re-authenticate with its credentials (e.g. email and password).
I was just wondering which status code would be the best fit in this scenario, as the spec says in case of a 403 Forbidden "authorization will not help".
I would not make access and refresh tokens interchangeable: Use Access-Tokens to access protected resources and use Refresh-Token to fetch new Access-Token from a special end-point. OpenID Connect works this way.
You would have one HTTP request more but HTTP codes would not be a problem and, in my opinion, you would get a cleaner code.