Comments (45)
An alternative way to use HTTPS immediately (including the first request) is to use a HTTPS RR DNS record. This is pretty new, but seems to be supported by Chrome and Firefox. This is specific to domains instead of sites, solving the tradeoff I mentioned earlier. I feel like this scales better and is more flexible, since site administrators can configure this themselves instead of requesting a change in the preload database. Of course, DNSSEC is required for optimal security.
from asvs.
I was thinking more about it and I'm leaning towards level 3 requirement, I think recommendation is not enough.
From @tghosth
This is quite high effort for a relatively small benefit (basically the first website load per browser)
What I did not point out clearly, is that without HSTS preload it is possible to serve any HTTP service from the Same-Site scope with the critical application. This is a way more important vector to eliminate compared to the first HTTP request to the application.
Let's say there is an application served from https://www.bank.tld
and an attacker can serve http://random.bank.tld
from their own-controlled or manipulated network. Same-Site scope means, that you can write cookies, which are valid for any *.bank.tld
site, and if cookies do not use the __Host-
prefix, you can manipulate cookie values for any application in the scope (using the same name, the same domain, and matching path).
Does it change your mind, @tghosth ?
from asvs.
There is a tradeoff here where requiring HSTS preload can lead to worse security.
For example, bank.tld has a customer portal on my.bank.tld and a legacy application on legacy.bank.tld. They cannot put HSTS preload on bank.tld, as that would break their legacy application. However, ASVS L3 says that their company portal should have HSTS preload. The "solution" is to move it to another domain, mybankonline.tld, and enable HSTS preload there. However, this is exactly what a phishing attack looks like: a similar but different domain, which makes it impossible to verify if the customer portal is actually owned by bank.tld. So this would give the wrong signal to customers, that not only bank.tld is trustworthy, but other domains that look similar as well.
This is not uncommon in the real world, for example with microsoftonline.com being an actual Microsoft domain. But I think this is not desirable from a security perspective.
from asvs.
Problem to solve: if the browser makes the first HTTP request to the application domain, it must be forced over HTTPS connection.
I would prefer to focus on this, and create a requirement such as:
Verify that HTTPS is enforced on the first connection to a site, for example by using HSTS preload or a HTTPS DNS record.
It is true that preload has some advantages by applying to the whole site instead of only the application domain. However, as described above this could also give an incentive to host things on another domain, which would reduce security.
I think the preload list is not an elegant solution, but I don't really have solid arguments for why you shouldn't use it.
why you should not use HSTS preload when you start building your company or organization from a blank page
If it's a security-sensitive site I would use HSTS preload.
from asvs.
I would prefer to focus on this, and create a requirement such as:
The issue with the initial problem to solve (#1941 (comment)) was closed and agreed as a recommendation.
I reopened the issue and made the "problem to solve" more clear #1941 (comment)
What I did not point out clearly, is that without HSTS preload it is possible to serve any HTTP service from the Same-Site scope with the critical application. This is a way more important vector to eliminate compared to the first HTTP request to the application.
I don't share the view on the given example. We have year 2024 and not a single at least somehow critical system should not have anything on http:
protocol in the internet for 10 years now. To give an example of a bank, I think it is not a good or realistic example.
Also, I think that using the main domain for some services does not stop spammers and phishing campaigns anyhow. From a browser security mechanism point of view - you should not serve random non-critical services in the same-site scope as your critical services. If it was served over http:
, was it trustworthy for the client anyway?
So, in short - the proposal from Sjord was a wording improvement for replacing current recommendation with the requirement. The question now is: should we protect the same-site scope against malicious http:
services with the HSTS preload?
from asvs.
This is quite high effort for a relatively small benefit (basically the first website load per browser)
Not sure I would want to mandate it.
from asvs.
basically the first website load per browser
Just in case - it is valid only for one application context.
HSTS preload covers a larger scope than just one application, it's more a company or organization-level guarantee, that everything goes over HTTPS.
from asvs.
from asvs.
It is not organization wide when an organization manages multiple domains.
Oh well. My point is, that the company or organization can manage larger risks at once by adding an entire domain to the HSTS preload list.
In my opinion, banks, governments, etc should have it set. Is it worth a requirement - I think a level 3 requirement would be reasonable, but I'm ok with a recommendation row as well.
It must be deployed on a domain-by-domain basis.
It may also include TLD.
from asvs.
I'm leaning towards a recommendation. Aside from anything else there is also the "bricking" risk if it is done unwisely.
from asvs.
Opened #1952
from asvs.
from asvs.
@elarlang if I understand correctly, the main problem here is that the domain does not have HSTS with sub-domains set at https://bank.tld
If it did have that (and the user was guaranteed to get there on first load), then your scenario would only work if the user had never been to https://bank.tld before.
Is that correct?
See for example that when you browse to https://www.stripe.com, the very first thing it does is redirect you to https://stripe.com which has an HSTS header
from asvs.
If it did have that (and the user was guaranteed to get there on first load), then your scenario would only work if the user had never been to https://bank.tld/ before.
Is that correct?
The boolean answer is true, but it requires some context.
For this "guaranteed redirect scenario" through the main domain, the preload
directive is not even needed to cover all subdomains.
But if you do so, then any given arguments against preload
are also taken down - in this case you also need to have all (including internal) services using correct certificates and served over https:
.
The main topic here is that it is easy to understand and implement if it is www.site.tld
and you redirect through site.tld
. You don't get that covered from all subdomains, e.g. selfservice.site.tld
, backoffice.site.tld
etc.
But @tghosth - just in case, you asked a question, but what was your point and message behind that?
I was thinking about it more and actually, there is a good question, is it in the scope for the application, which is served from backoffice.site.tld
, as it requires configuration somewhere else? On the other hand, it is in the scope from "architecture choices" point of view, that you need to be sure you serve only trusted services from same-origin and same-site scope.
from asvs.
I was thinking about it more and actually, there is a good question, is it in the scope for the application, which is served from backoffice.site.tld, as it requires configuration somewhere else? On the other hand, it is in the scope from "architecture choices" point of view, that you need to be sure you serve only trusted services from same-origin and same-site scope.
So this complexity makes me feel even more uncomfortable about mandating HSTS at the root tld level. The number of moving parts to implement HSTS and preload at the site.tld
level might be to large, even for L3.
from asvs.
I agree, that effort can be huge for some legacy systems, when you have "mess in the house".
At the same time, for new organisations and application, it must be cornerstone for building things.
The price is clear - control over Same-Site scope. Then no-one can use trusted domain for phisnig (yes, it does not stop phising), no cookie manipulation for apps, no cookie leakage for apps (in case those are misconfigured with Domain=.site.tld
).
Also note, that we give similar direction with other requirement:
50.1.1 [ADDED, DEPRECATES 3.4.5] Verify that separate applications are hosted on different hostnames to benefit from the restrictions provided by the "same-origin policy" including how documents or scripts loaded by one origin can interact with resources from another origin and hostname restrictions on cookies.
Me and you can theorize here further, but I think we need some additional views. Probably it's worth asking in social media, why big companies use or don't use the preload
directive. Maybe there are some new arguments to discover.
from asvs.
OK so I think these are our possible suggestions:
- HSTS preload at the top level (i.e.
site.tld
) with the subdomains attribute should be a recommendation. - HSTS preload at the top level (i.e.
site.tld
) with the subdomains attribute should be an L3 requirement. - The app should always redirect to the top level (i.e.
site.tld
) which should have HSTS configured with the subdomains attribute (but we don't mandate preload). - HSTS preload for the application domain with the subdomains attribute should be an L3 requirement.
If I understand correctly, you support 2) and I am most incline to support a combination of 1) and 4).
Do you agree with my interpretation? If so, I will try and get wider feedback.
from asvs.
I think we have only 2 options - 1 and 2.
Option 3 is something that I could call the "development stage" for implementing HSTS preload. The entire redirection thingy seems risky, but - technically, (I have not tested it) - is there a navigation request required to have the HSTS statement set to the browser, or for example, loading an image is enough? E. g. if from application.domain.tld
there is HTML at the beginning of the document:
<img src="https://domain.tld/preload.jpg">
Option 4 is not supported by HSTS preload list. If you try to check the subdomain (which is not www.
, you'll get an error message:
subdomain.domain.tld
is a subdomain. Please preloaddomain.tld
instead. (Due to the size of the preload list and the behaviour of cookies across subdomains, we only accept automated preload list submissions of whole registered domains.)
Note: "...with the subdomains attribute" - using the preload
directive requires, that includeSubDomains
is set
The includeSubDomains directive must be specified.
So, in my opinion - our options are simple - should we only recommend it or can we require it?
For the perspective - most likely the new ASVS version will be valid for "non-braking-changes" for many years, this is something to keep in mind.
from asvs.
From my point of view, the question should be: Are there any valid reasons not to have HSTS preload as a requirement?
Context: level 3 requirement for applications with critical business value and/or highly sensitive data.
from asvs.
Ok so the basic question is, should HSTS preload at the top level domain be a L3 requirement or a recommendation?
Curious to see what @jmanico @ryarmst @Sjord @ImanSharaf @EnigmaRosa @csfreak92 @meghanjacquot have to say
from asvs.
My mindset for requirements that may be difficult or complicated for legacy systems.
Legacy systems are built in their time and are expected to be not compatible by default with new requirements. It is the same way everywhere - take for example requirements for new cars, requirements for building new houses, etc. There are reasons for having new requirements.
If those new requirements are reasonable to require for new systems that are built today and from scratch, we should have those requirements in. We don't need to legalize old and insecure systems to be compatible with new standards.
from asvs.
from asvs.
See https://hstspreload.org/ :
If you maintain a project that provides HTTPS configuration advice or provides an option to enable HSTS, do not include the preload directive by default. We get regular emails from site operators who tried out HSTS this way, only to find themselves on the preload list by the time they find they need to remove HSTS to access certain subdomains. Removal tends to be slow and painful for those sites.
This might be a good reason for not mandating this.
from asvs.
This might be a good reason for not mandating this.
I watch a bit differently - it says clearly, do not include it by default. It is recommendation about the process, how to implement HSTS preload into your infrastructure. It does not say "don't use it".
@randomstuff - The main question for me is from (#1941 (comment)): is there any good reason to say, that why you should not use it when you start building your company or organization from a blank page e.g. you don't have any legacy to carry? What is your opinion on this?
from asvs.
Ok so both @elarlang and @jmanico say it should be a requirement so I am ok to go with that.
@elarlang do you want to open a PR to V50?
from asvs.
from asvs.
from asvs.
Hi @Sjord,
as I understand, then domain based solution does not solve the "control your same-site scope" effect. Correct? (See my comment here: #1941 (comment))
I don't want to have too much impact from "Let's do the legacy legal" behavior and I have the question to you: Is there any good reason to say, that why you should not use HSTS preload when you start building your company or organization from a blank page e.g. you don't have any legacy to carry? What is your opinion on this?
from asvs.
from asvs.
Yeah it does seem like HTTPS RR doesn't solve the problem that elar mentions in his comment: #1941 (comment)
Is that correct @Sjord?
from asvs.
@set-reminder @tghosth to open a PR to require preload for L3 in 20 days if no response from @Sjord
from asvs.
⏰ Reminder
Wednesday, July 3, 2024 12:00 AM (GMT+02:00)
@tghosth to open a PR to require preload for L3 in if no response from @Sjord
from asvs.
from asvs.
Let's say there is an application served from https://www.bank.tld and an attacker can serve http://random.bank.tld from their own-controlled or manipulated network.
The question now is: should we protect the same-site scope against malicious http: services with the HSTS preload?
This is called "subdomain takeover" similar[1]. Do we have requirements for this? I think that would address your top concern, @elarlang
Now regarding the "first hit" problem.
I suggest supporting only HTTPS and not HTTP at all. For APIs, I never enable port 80 for HTTP. It's only websites that sometimes enable port 80. Since browsers have started defaulting to HTTPS[2], the chance of making HTTP requests to a site on the first hit has decreased.
[1] https://blog.chromium.org/2023/08/towards-https-by-default.html
[2] https://developer.mozilla.org/en-US/docs/Web/Security/Subdomain_takeovers
from asvs.
Subdomain takeover - we did not add this requirement (#1788) as it was out of scope (infrastructure question). It is related from the "trusted same-site scope" point of view. But if you are able to take over the subdomain and there is the HSTS preload, how do you get trusted certificates for serving a malicious service from the subdomain? So HSTS preload may have a strong say against this vector as well.
For HTTPS only we have 9.1.1
from asvs.
But if you are able to take over the subdomain and there is the HSTS preload, how do you get trusted certificates for serving a malicious service from the subdomain?
If you have taken over the subdomain you can just request a valid certificate from Lets Encrypt or any other CA, right?
from asvs.
If you have taken over the subdomain you can just request a valid certificate from Lets Encrypt or any other CA, right?
I'm not an expert in that area. My logic (not served as a fact) says that you should not be able to do it if you have a wildcard certificate on the main domain.
from asvs.
Wildcard certificates do not inherently prevent certificate issuance for specific subdomains. If an attacker controls sub.example.com, they can still request a certificate for sub.example.com because the control over that specific subdomain can be shown to the CA. For example, some CA's provide a token that must be placed at a specific URL on the subdomain. The CA then checks if the token is accessible at that URL.
CAA[1] does prevent certificate issuance from different CA's. That's a better control than wildcard certs to (somewhat) prevent subdomain takeover.
[1] https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization
from asvs.
Hi @elarlang, can you confirm if you have a specific problem with @Sjord's wording? To me it seemed to match out overall approach of being positive, solving a specific security problem but not being too prescriptive.
Verify that HTTPS is enforced on the first connection to a site, for example by using HSTS preload or a HTTPS DNS record.
What do you think?
from asvs.
I still have the same question #1941 (comment)
So, in short - the proposal from Sjord was a wording improvement for replacing current recommendation with the requirement. The question now is: should we protect the same-site scope against malicious http: services with the HSTS preload?
I don't have the answer to that, yet.
from asvs.
Oh yeah, thanks for the clarification. would an HTTPS DNS record solve "protect the same-site scope against malicious http: services"? I am guessing not?
from asvs.
No.
@elarlang correctly explained the attack scenario earlier:
Let's say there is an application served from https://www.bank.tld and an attacker can serve http://random.bank.tld from their own-controlled or manipulated network.
HSTS preload on bank.tld would prevent that.
is it in the scope for the application, which is served from backoffice.site.tld, as it requires configuration somewhere else?
Sometimes the application developers are in control of the site, and sometimes they are not. It varies, depending on company structure. That does not necessarily mean this cannot be a requirement. We also require TLS connections to the database, even though the database server is managed by someone else.
from asvs.
So @Sjord it sounds like HSTS preload covers all the attack scenarios. It leaves us with that theoretical issue of having to move to a different domain but I am not sure that is enough to justify not requiring it for level 3.
from asvs.
@tghosth to open a PR to require preload for L3 in if no response from @Sjord
from asvs.
if no response from @Sjord
I think I have made my case, I wasn't planning on responding to this further.
from asvs.
Related Issues (20)
- Minor V7 changes HOT 2
- Italian Translation HOT 1
- V11 rework by @jmanico HOT 16
- update 50.2.1 (v4.0.3-14.4.3) and/or split requirement for content-security-policy HOT 13
- move or merge 8.3.5 to V7 HOT 3
- URL Safety HOT 23
- proposal/discussion: OAuth - disallow web application to be OAuth public client (and to have direct communication with OAuth token endpoint) HOT 4
- proposal/discussion: OAuth - (for 1st party usage) only used (by the client) communication options must be allowed by authorization server HOT 4
- proposal/discussion: OAuth - separate requirement for redirect_uri string-match registration and handling HOT 8
- discussion: OAuth - using OAuth just for authentication HOT 7
- proposal/discussion: JWT - 3.5.6 add "type", and rephrase it to describe the goal HOT 8
- proposal/discussion: OAuth: requirement for refresh_token lifetime
- V51: Additional OAuth/OIDC proposals HOT 6
- discussion OAuth/OIDC: accepted flows and grants HOT 7
- 4.3.1 and 4.3.3 HOT 7
- Password Storage Algorithms 2.4.1 revisited HOT 3
- Make 2.1.14 easier and more simplified HOT 7
- Implement Requirement for Anomalous Behavior Detection HOT 4
- cloud config scanning HOT 1
- Link checker is temperamental and apparently deprecated HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from asvs.