Based on the RFC, HTTP Strict Transport Security (HSTS), the includeSubDomains states:
6.1.2. The includeSubDomains Directive
The OPTIONAL "includeSubDomains" directive is a valueless directive
which, if present (i.e., it is "asserted"), signals the UA that the
HSTS Policy applies to this HSTS Host as well as any subdomains of
As a pentester being able to find the subdomains for a site comes up often. So I wrote a tool, SubBrute that does this quite well if I do say so my self. In short, this is better than other tools (fierce2) in that its a lot faster, more accurate and easier to work with. This tool comes with a list of real subdomains obtained from spidering the web. ...
Subdomains can often be used for different purposes, and as a result they can be using different web applications possibly hosted on different equipment.
Not every website on every subdomain needs to follow the policy of the domain, it can even be the case that sites on subdomains do not support HTTPS due to lack of support in the application and/or not ...
According to a paper published in Blackhat 2013, it isn't enough for you to implement Double-Submit Cookies in its own sub-domain (e.g. secure.host.com). You really must control all sub-domains:
2.1.1 Naïve Double Submit
Double submit cookie CSRF mitigations are common and implementations can vary a lot. The solution is
tempting because it’s ...
What's the purpose of that in terms of security / hacking?
The hostname(s) of resources can provide valuable information to narrow the scope of an attacker's task by providing information about available machines and resources. The underlying space of network (IP) addresses is sparsely populated (and IP:port combinations even more so), so narrowing down the ...
It's best to let the site owner decide whether subdomains are affected, just as the site owner decides whether to use HSTS at all. The extra flexibility could help improve HSTS adoption by reducing compatibility obstacles.
Some of the subdomain services may not have an HTTPS server installed yet. There are a few cases where it's not important security-wise ...
Based on the few details of this setup and some guess work what you might use this setup for the following problems come to mind:
with local privilege escalation exploit one might break out of the chroot and affect other users on this system.
if used in a web context it is possible to set/override cookies into the others domain and thus change the behavior ...
Subdomain enumeration techniques are passive methods used during a pre-attack phase or during information gathering phase of a pentest assignment.
Enumerating subdomains is crucial as they may point to different parts of a web application or may lead to another website hosted on another server with a different IP address. This allows you to come up with an ...
Although all XSS attacks trump CSRF protections, these require differing effort from the attacker. A simple protection such as a token is easy for an attacker to get via an XSS attack, as they can simply read the token value from the DOM and use it in any subsequent form submits. A sensitive form that requires password or OTP reauthentication is trickier to ...
1. Zone transfer
Some nameservers allow for DNS zone transfers to anyone on the internet, usually unintentionally. In this question, it is explained further: DNS zone transfer attack.
Tools for zone transfers
The second answer on that question mentions how to test for it for both Windows and Linux:
> server <DNS you are querying>
Although we don't know all the details about the OS you are using or about the different software's you use the potential attack is a Privilege Escalation that can be done.
The attacker (in this case the person you gave a user to) can manipulate exploits found in your server to escalate his user and gain access to unwanted privileges and escape the "...
There a few cases for this:
Compromised hosts, say you have a company, company.xyz, a wildcard and have a few machines on there; blog.company.xyz, www.company.xyz, mail.company.xyz, vpn.company.xyz. If someone compromises your blog, and gets a hold of the private key of that certificate, all your domains are compromised. Having individual certificates for ...
In this answer, you can detect from DNS if they have a wildcard domain, this will save you time (and you won't have HTTP queries to the domain)
Taken from the serverfault post:
# dig +short '*.not-a-real-domain.com'
Yes, this is possible. When the www or root domain are accessed, the users will see the green bar in the browser, since those sites will be returning the EV certificate. When a user loads a page from another sub-domain, it will be served over HTTPS, but without the green bar, since those sites will be using the wildcard non-EV certificate.
If the ...
The real risk is having incoming access to your home network at all. The fact that it is accessible through DNS does not significantly add to the risk. The "bad guys" find open ports through port scanning, not through lookups by name. Edited to add: Unless you are a high-profile target. If your domain is something like, um, Target.com or HomeDepot.com ...
There is no such thing as an "SSL domain".
There is no NUL-handling bug in SSL, which is a specification. Only bugs in implementations. Lots of bugs. In these bugs, there never was a NUL character in the hostname at all, only in the certificate.
Widely used implementations such as OpenSSL now protect against this, but testing is surely still worthwhile.
Subdomains cannot be registered.
Domains are registered, and then the designated Nameservers (DNS Servers) are able to control the subdomains.
In many cases, the Registrar is also handling Nameservers, but sometimes the Registrar is instructed to use 3rd party Nameservers.
The Nameserver is able to serve specific DNS records for each subdomain.
In this ...
Is it possible for a 3rd party to own a sub-domain of my xxx.com site?
No, other folks cannot own register subdomains for a domain which you have already registered.
Here's the ownership tree.
The domain name (e.g. example.com) is registered by you with a Registrar. (e.g. Namecheap, Network Solutions, etc.)
On the registration, you can ...
You are using the wrong tool for the Job!
Subdomains are not private. They can't be made private either. The reason why they can't be is because of DNS, or Domain Name System. Without going into too much detail, DNS is a database of all domains and subdomains, and values associated to them. A very simple example:
User: "DNS Resolver, which IP does ...
A wildcard certificate is a public key certificate which can be used with multiple subdomains of a domain. Depending on the number of subdomains an advantage could be that it saves money and also could be more convenient.
Note: But Only a single level of subdomain matching is supported
The workaround could be to add every virtual host name in the Subject ...
Yes, they could poison cookies on your domain to execute say a Session Fixation attack.
The attacker visits your main website www.example.com and gets a session ID.
They entice their victim to visit ...
The first answer doesn't technically answer the question.
There's only one official method of doing this using the dig command:
dig @ns.thenameserver.net example.com axfr
AXFR is a method of domain transfer and if the nameservers are configured to allow the command to be executed then it would give you the full NS record for that domain ...
Jason Haddix wrote my favorite subdomain/hostname discovery tool that depends on a very-recent version of recon-ng -- available here -- https://github.com/jhaddix/domain
subbrute is decent, fierce -dns <domain> works great, dnsmap <domain> -r file.txt is also valid, and I don't see any reason to dislike knock -wc <domain> (although the ...
Yes. An example:
blog.torproject.org has a non-wildcard cert on 188.8.131.52
www.torproject.org uses *.torproject.org on five apparently-distinct machines 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199
research.torproject.org uses *.torproject.org on 188.8.131.52
I may be confusing at first to the (rare) people who actually examine the ...
Yes, you can issue a wild card certificate for your domains.
No, CAs probably don't exchange data, nor would they care if some other CA purchased an overlapping certificate.
In other words, you can have as many wildcard, and non wildcard certificates as you want. After you acquire the certificate you have to add that certificate into the web server.
NO! You have now shared your key with someone you can't trust to keep it safe.
YES! This way if their key gets compromised or your key gets compromised, the other key is safe, and so are those systems/information.
YES! At this point it is still you paying the cost for the key, and them using it. Six of one, but no email the other. This would be the ...
tl;dr: different things, both useful for different scenarios, IP whitelisting is not a bad sign
You are indeed comparing apples and oranges.
IP-based filtering happens at the network layer of the OSI model, whereas certificate validation happens on the transport (and/or application) layer.
Allowing access only to/from specific IP addresses reduces the ...
Yes, this should apply to all subdomains (see Steffen Ullrich's comment for caveat).
In foo.bar.foobar, foo is a subdomain of bar.foobar, and bar is a subdomain of foobar, so therefore foo.bar.foobar is an indirect subdomain of foobar.