I work on ASP.NET and was just reading this from the amazon directory http://docs.amazonwebservices.com/AmazonS3/latest/dev/RESTAuthentication.html where it states
Informally, we call this process "signing the request," and we call
the output of the HMAC algorithm the "signature" because it simulates
the security properties of a real signature. Finally, you add this
signature as a parameter of the request, using the syntax described in
this section.
When the system receives an authenticated request, it fetches the AWS
Secret Access Key that you claim to have, and uses it in the same way
to compute a "signature" for the message it received. It then compares
the signature it calculated against the signature presented by the
requester.
But i presume both the requests wont be same right. Request is signed (great!!) but HMAC of the response from the client browser is going to be different since it contains extra data Right? so how come requests can validate even though they are valid
You need to read the whole of the paragraphs you quoted from. Right before the piece you quoted it says:
To authenticate a request, you first concatenate selected elements of the request to form a string. You then use your AWS Secret Access Key to calculate the HMAC of that string.
So you calculate your HMAC from those selected elements, and when you submit the request, the server calculates an HMAC from those same elements, and then they are compared.
Related
As a preface I'd like to claim I have some understanding of how the HTTP-supported authentication is supposed to work according to RFC 7235.
I am specifically interested to know how a client is supposed to know, after authenticating, which URIs on the server it is expected to provide same authorization (through the Authorization header) bearer for? Furthermore, is there any provision by HTTP to assist client in determining which Authorization headers it (the client) may have available (through whatever means it acquires them -- "login" form/dialog etc), would go with which realm(s)?
A realm doesn't seem to be specified in the form of an URI or even a regular expression of an URI, it's a value the interpretation of which appears to be left to the HTTP client application. Of note, a "Protection Space (Realm)" is defined, quoting:
A protection space is defined by the canonical root URI (the scheme and authority components of the effective request URI (see Section 5.5 of RFC7230) of the server being accessed, in combination with the realm value if present.
The above is all well and good, but it doesn't facilitate client mapping realms to URIs that may require authorization.
Say my Web server returns a response with status code 401 and the WWW-Authenticate: Bearer realm="The hangout" header line, for a request with a given URI, let's say /foobar. That makes it obvious that subsequent requests to the particular URI must include Authorization header line corresponding to solved challenge (as the client authenticates the user). No problem there. But what about e.g. requests with URI(s) that have the same pathname - those starting with /foobar/ -- is there an implication here that the same Authorization value is expected for these as well? What about entirely unrelated URI pathnames [on the same server]?
It would seem beneficial for the kind of authorization negotiation HTTP already does, to somehow relate or facilitate said relation of realms to URIs. But maybe I am missing something very obvious. Does HTTP do something along of what I am describing? Does it facilitate it in any way, at least, beyond leaving it entirely to the application? How would one realistically let the client determine which authorization bearer to send for which requests? Must it always get a 401 and a challenge response first, before knowing for sure requests to the particular URI and only said URI, must include related authorization bearer?
HTTP is a stateless protocol that deals with a request-response pair. The protocol does not deal with any information that would describe the concept of a "page", "site", "application", etc. Even though it deals with hypermedia, the protocol itself doesn't go beyond the concrete request. This means that you won't get any information from the protocol itself about any other paths under the same domain that are in the same authentication realm. This is left to the documentation of APIs or websites.
It seems to me that your research is centered on one type of authentication process that we call basic auth, know they are some other ways to authenticate a user and that they might suits your needs better as basic auth is kinda old as you can see on that RFC you linked.
To my understanding, the principle behind basic auth is to have a simple process based on challenges. When your client asks for a resource and that resource is protected by authentication, the server responds with a challenge : 401 Unauthorized with a header WWW-authenticate: Basic realm="some realm". The client then know the resource is restricted and depending on the realm, knows if it can have access (or asks the user for credentials for that realm), and try to access with a basic auth header : Authorization: Basic viFWGrwehryfviehtNRBRGWrwGERThRGE. You then repeat that process every time you need a resource.
HTTP and basic auth don't implement any sort of deeper and more complex system for authentication like you're searching for. It's one of the simplest system as its name implies and has not a lot more to offer. I'd even add that it's one of the riskier way to authenticate a system (even using SSL cert and cert pinning) as the client must send credentials for every single authenticated resource request.
In case you want to search other ways to authenticate requests, here are some :
OAuth (2.0) (most secured and complex)
Bearer (JWT or session tokens)
API keys
I need to add a signature to my request before it is tested. Hence before Pact testing happens on provider side, i need to add a signature which is generated based on the entire request. Is there a way to get the request before Pact Verification happens, so i can generate and add the signature ?
PS: I already added some other headers using CustomHeaders. But i need the request itself to generate the signature. This is for C#
I want to create an application which is similar to this - A client (identified by user id) sends a REST API call to the server. The server queries database to check if this user has a badge before. If it has, it doesn't do anything. Otherwise, it marks in database that the user is granted the badge and it sends an email to the user.
PUT /user//badge/
POST /user//badge/
My question here is which http method should I use here? PUT or POST?
It is idempotent in the sense that email is sent in only the first request and subsequent requests don't do anything other than querying the db.
What http method do books recommend to be used in this case?
If it's idempotent then it should normally be a PUT, as is clear from from RFC 7231, section 4.3.4:
The fundamental difference between the POST and PUT methods is
highlighted by the different intent for the enclosed representation.
The target resource in a POST request is intended to handle the
enclosed representation according to the resource's own semantics,
whereas the enclosed representation in a PUT request is defined as
replacing the state of the target resource. Hence, the intent of PUT
is idempotent and visible to intermediaries, even though the exact
effect is only known by the origin server.
can anybody explain what exactly the cookieToken parameter is when I call the function in MVC: AntiForgery.Validate(cookieToken, formToken);
Is it possible to use the cookieToken as a Session identifier to identify the user and current session?
No.
ASP.Net generates a random Cross-site Request Forgery (CSRF) Token on every request (even for the same user). You can verify this by going to your website and looking at the source. There will be a hidden field "__RequestVerificationToken" that will contain a string of random letters and numbers. When you refresh the page it will randomly generate a new set of letters and numbers.
This is not to identify a user to a particular session, but to identify a user to a single request.
To read more on CSRF attacks to understand the purpose of this token, read OWASP's Top 10 on Cross-Site Request Forgery
In an ASP.Net web app, which runs on HTTPS and has RequireClientCertificate set in web.config, I need to receive the client certificate of the user and digital signature of the request on the server. The certificate is found in HttpContext.Request.ClientCertificate, but I can't find the signed data. The post params are automatically decoded and decrypted, but I need the signature too. Does anyone know where is it found or is it possible to get it?
One more question, when the browser asks for your certificate and hands it to the server, does it encrypt the whole HttpRequest with your private key or just a part of it (for example post params)?
Thanks for any help
One more question, when the browser asks for your certificate and
hands it to the server, does it encrypt the whole HttpRequest with
your private key or just a part of it (for example post params)?
Firstly, it doesn't make sense to "encrypt with a private key": you sign with a private key. While some algorithms (e.g. RSA) use very similar procedures to encrypt and sign, "encrypt" means "hiding" something: you're not hiding anything if anyone with the public key can decipher it.
Secondly, SSL/TLS uses symmetric keys (negotiated during the handshake) for encryption, not the keys in the certificates. The whole HTTP request will indeed be encrypted in this case.
The certificate is found in HttpContext.Request.ClientCertificate, but
I can't find the signed data. The post params are automatically
decoded and decrypted, but I need the signature too. Does anyone know
where is it found or is it possible to get it?
What's signed when using a client certificate is the handshake messages, not the HTTP request. Once the appropriate verification has been made by your SSL/TLS stack, it's unlikely to be of any use, either technically or administratively. (This is why it is generally not accessible.)