Is it possible to at a domain level (meta tag / HTTP header) to indicate to the web browser that no form of data persistence should be allowed.
Similar to how hsts tells the browser, you should ALWAYS expect to connect to this domain using SSL. Is there a way to tell you browser you should NEVER storage any for of data for this domain (Cookies / Local Storage / IndexDB) etc?
Related
We are experiencing a Dodos attack (I guess) as we are receiving millions of HEAD request to our web site.
We have secured it but unfortunately Azure has the default domain xyz.azurewebsite.com and the "attacker" is making request to that URL. Even if I add a network restriction the server still goes down as to produce the "403 forbidden" page I guess it uses some resource.
Any Ideas to prevent this ?
I have an application where users can give an API URL and then that URL is hit on a schedule (example: fetch data from SpaceX API every 25 minutes).
If the server is a node.js app, are there any security implications I need to worry about? By fetching data from an unknown URL (using node-fetch), what could go wrong?
Yes, your app is exposed to SSRF,
In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL which the code running on the server will read or submit data to, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like http enabled databases or perform post requests towards internal services which are not intended to be exposed.
For example, if your app is hosted on AWS EC2, your attacker can provide a url (http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name) to local AWS meta-data services, which may expose AWS token to the attacker.
This attack assumes that the result of the request is returned to the attacker.
Mitigation of SSRF attacks
I have a website that will have customers logging into:
www.example.com/login
and will do their authenticated tasks here
www.example.com/dashboard/
Customers will also have their own public facing content here:
customer1.example.com
The public facing content is where they can't write their own content, so I am concerned if they write some javascript etc. to grab cookie information somehow i.e. they write javascript, and when a different user goes to their site who was authenticated on www.example.com, the javascript will grab their session cookie and send it over to another website.
When cookies are stored at the root domain and sub-domain, are they free accessible at each level?
Trying to understand the security implications.
Cookies will be accessible for all subdomains of the host you specify in the Domain attribute.
If you set Domain=example.com, the cookies will be available to all subdomains of example.com.
A cookie with Domain=www.example.com will only be accessible for www.example.com and subdomains of www.example.com (e.g. foo.bar.www.example.com) - no worries if you do that.
However, note that this also means it won't be accessible from example.com.
The most restrictive option is to omit the Domain attribute, by not sending it at all. In that case, the cookie should only be accessible for the hostname that sent it. That is, if you send it from www.example.com, it will only be sent back to www.example.com and not even to its subdomains.
This is all explained in RFC 6265, section 4.1.2.3.
After taking a look at the HTTP State Management Mechanism Spec specifically 4.1.2.5 where it mentions:
The Secure attribute limits the scope of the cookie to "secure"
channels (where "secure" is defined by the user agent). When a
cookie has the Secure attribute, the user agent will include the
cookie in an HTTP request only if the request is transmitted over a
secure channel (typically HTTP over Transport Layer Security (TLS)
I was wondering if my setup has this set up correctly. I have a hapijs server and an nginx proxy server that it sits behind. The nginx server is configured for HTTPS (I can access it via https://..., anyway). Now there are ways to provide certs to the hapijs server to provide it TLS. My question is: is this necessary? The connection between the user's browser and my server is protected with TLS and then all that communication happens without sending anything over the wire so I would assume it would be okay.
I may be way off base here so maybe someone can point me in the right direction if I am.
The "secure" attribute of cookies is handled by the client (the web browser) and not by any proxy servers (at least that that I'm aware of!).
So you should be fine as long as the endpoint the browser connects to is secure.
This is a very common set up to only secure traffic at the end point - providing you are comfortable with the the security of the link between endpoint and final destination (e.g. same machine or internal network).
Of course an internal network traffic can be sniffed by someone onsite (e.g. an employee) so https all the way is best from a security point of view, but using http from endpoint to final destination should not prevent "secure" cookies being sent on from my experience.
If using external network as the first server (e.g. CDN) then it's strongly advisable to use https all the way to a secure endpoint, though again they will not be stopped.
I have a website that came with a SSL site for HTTPS but its on a different server. Example being
my website:
http://example.com
my SSL site:
https://myhostingcompany.com/~myuseraccount/
So I can do transactions over HTTPS and we have user accounts and everything but it is located on a different domain. The cookie domain is set for that one.
Is there a way I can check on my actual site to see if a cookie is set for the other one? And possibly grab its data and auth a user?
I think this violates a major principle of security and can't be done for good reasons, but am i wrong? is this possible?
You can setup a service on either site to handle RPC via HTTP POST requests. You can make it require some sort of session that can only be created by your sites. However, whatever can be accessed over that shared session on the HTTPS site will have no guarantee of confidentiality or integrity.