I have a web application behind an OIDC reverse proxy -- in other words, when I visit this application I am redirected to my identity provider, I log in and my browser sets a cookie which is used on subsequent requests to prove that I have logged in.
This cookie has the HttpOnly flag set, which I understand to be best practice to prevent XSS vulnerabilities being exploited by a malicious website.
However, as expected, Javascript within my application does not have access to the login cookie, so in my browser's console I see requests back to the application (trying to update dynamic content through both HTTP requests and websocket connections) being redirected to my identity provider (and blocked by CORS policy) since they do not have access to the login cookie.
Does this mean that such an architecture cannot use Javascript to call back to the application?
Is it common to disable the HTTPOnly flag to allow Javascript to work in such a case?
My understanding is that Javascript from a malicious website at a different origin trying to access my application would be blocked by CORS anyway, so would keeping the HTTPOnly flag only help against attacks where the attacker managed to inject Javascript into my application?
Does this mean that such an architecture cannot used Javascript?
No. It means JS cannot read data from the cookie.
I see requests back to the application (trying to update dynamic content through both HTTP requests and websocket connections) being redirected to my identity provider (and blocked by CORS policy) since they do not have access to the login cookie.
The CORS policy should not block requests because cookies are missing.
If a cookie is missing then it is probably because you are (a) getting your origins mixed up and that origin doesn't have a cookie or (b) you didn't enable the credentials option for a cross-origin request.
Is it common to disable the HTTPOnly flag to allow Javascript to work?
No.
My understanding is that Javascript from a malicious website at a different origin trying to access my application would be blocked by CORS anyway, so would keeping the HTTPOnly flag only help against attacks where the attacker managed to inject Javascript into my application?
Yes. XSS attacks are so common that there are many tools to mitigate against them. This is one of them.
Related
I have a web application that serves only static contents - HTML, CSS and JavaScript. I have another application which is an ASP.NET Web API. Both applications are on same machine on different ports (for testing purpose and they could be on different machine or domain in production environment). When I browse the web application, it gets both cookie as well as form token of Anti CSRF on first ajax call from Web API. So I am setting the body token as header with setRequestHeader function of XMLHttpRequest. It doesn't seem there is any need to set the cookie token since cookies are restricted with HttpOnly Attribute for a security reason and as far as I know browser is responsible to send the cookie to whichever domain the cookie belongs to.
However, when I make consecutive ajax calls, instead of both these tokens being passed back to server, only the header token is being received by the server.
Currently the Web API is set with CORS restriction for the web application. But if the problem was related to cross origin then I guess, headers could not have been passed as well, correct me if I am mistaken.
So can anyone help me with this problem? I just want to be able to send cookies from one application to another without compromising in terms of security.
Take a look Cookies With My CORS and Set-Cookie in HTTP header is ignored with AngularJS
If I have an HTML page served over HTTP at http://example.com:123, and another served over HTTPS at https://example.com:456/some_app, is there any risk to the HTTPS app? Note that the following mitigations are assumed to be in place:
The HTTP page is entirely unauthenticated and contains public information
The cookies for the HTTPS page are marked secure
The HTTPS page uses a standard anti-CSRF patter such as double submit
The main risk that I see is that an attacker could intercept the HTTP request and send back a page with malicious Javascript. While this is undesirable, I can't see any way that the attack could escalate. Despite the the overly permissive access controls on cookies, the attacker should not be able to steal the HTTPS page's cookies, because they are marked secure. As far as cross origin requests go, requests made by the HTTP page are considered as coming from a different origin, so the CSRF protections work there.
Are there any attack venues that I'm missing? Or is the HTTPS app reasonably safe?
The "secure" attribute of cookies prevents the cookies being sent with a http request so they are only sent with https. However there is nothing to prevent javascript on the http page reading the cookie if, for example, it has been tampered with either in transit to include extra javascript or was vulnerable to a XSS flaw.
This could be remediated by setting the HttpOnly flag as well as the secure flag but that will may not work for your Double protection CSRF implementation if JavaScript is needed to read the cookie.
EDIT: Comments below state that Chrome (at least) prevents this when Secure flag is set but I cannot see this explicitly called out in the RFC and in fact section 8.5 states that cookies do not always follow the same restrictions for scheme and path when accessed through document.cookie. It also gives the example of path restrictions being ignored when accessed locally using document.cookie - though admittedly doesn't explicitly mention whether Secure cookies can be read from javascript on non-https pages. I would err on the cautious side and so assume they are not secure from javascript on http pages unless HttpOnly flag is set.
The other issue is that there is nothing to stop the Http page setting the cookie, and overwriting the existing one. Again this could be achieved by intercepting the http page response and adding a Set-Cookie header, or by using javascript on the page of vulnerable to XSS. While you might think overwriting a cookie wouldn't cause too many problems it could log you in as someone else for example without the person realising at which point they might enter other private data under this incorrect login.
Of course your https page could also be vulnerable to XSS too but the interception attacks mention are only an issue on unsecured http (and I'm including poorly configured https in that btw). Additionally http pages are typically handled with less care by users and developers alike and also load insecure third party content without error. So could be more vulnerable to XSS or other issues.
This is not to mention the fact that, with only a port number difference, your http site could be intercepted and made to look like your https site as a phishing site in the hope your visitors are happy with the server name and don't notice the incorrect port.
And those are just a few issues I can think of.
I would strongly advise not allowing http and https on the same server name, would suggest https everywhere and even go as far as recommending HSTS to ensure this.
Good Morning,
I'm developing an app in ionic and there are some $http requests(angular) that send data to a server controller(yii 1) to save data on database. I finished my app, but it doesn't have security. I was wondering how to protect it, because right now anyone if look my $http request can know what parameters have to send, and kill my app.
What I should do to protect it? Maybe through tokens? I'm really lost with security methods.
Thank you so much,
Carles.
well When you research web application security you will come across Cross-Site Request Forgery (CSRF). This attack vector is taking advantage of cookies, but in a preventable way.
Most attacks focus on stealing your cookies because nearly every website uses cookies as a form of authentication. The setup is this: when a user logs into your server, you set a cookie in the browser. This cookie contains a unique ID which is a link to the user’s session information in your database. The browser supplies this cookie on future requests, and the server knows who you are.
On the surface this sounds not-so-bad, but here is the catch: the web browser can be tricked into making requests to your server, even if the end-user didn’t perform the action themselves.
Using POST Requests
It is sometimes thought that using proper form-based POST requests will mitigate this attack, but that is not true.
Using HTTP-Only or Secure cookies
While you definitely should use these flags on your session cookie, they don’t implicitly stop the attack: the browser still sends the cookies to your domain when a request is made to your domain. Your server does not know if this is a real user or an attack.
How To Prevent CSRF
You can achieve this by relying on a set of rules that browsers respect, called the Same-Origin Policy. This policy asserts that certain sensitive operations are performed by JavaScript code that is running on our website, not some other website.
Angular packages the CSRF token approach, making it simpler for us to implement. For every request that your Angular application makes of your server, the Angular $http service will do these things automatically:
Look for a cookie named XSRF-TOKEN on the current domain.
If that cookie is found, it reads the value and adds it to the request as the X-XSRF-TOKEN header.
Thus the client-side implementation is handled for you, automatically! But this does leave the server side pieces in your hands. You will need to do the following parts:
During login: create the CSRF token (with a random, un-guessable string), and associate it with the user session. You will need to send it on the login response as the XSRF-TOKEN cookie.
Assert that all incoming requests to your API have the X-XSRF-TOKEN header, and that the value of the header is the token that is associated with the user’s session.
That’s it! With a little bit of backend work, you now have a strategy which protects you from CSRF attacks.
you will find a working example of how to prevent CSRF attack here
and for theory of understanding CSRF attacks please follow this reference
I'm attempting a slight variation of the Google+ web sign-in server side flow as described on the Google Developer's website.
Google's gapi code is giving this error message:
Uncaught SecurityError: Blocked a frame with origin "http://my-development-system.dev" from accessing a frame with origin "https://accounts.google.com". The frame requesting access has a protocol of "http", the frame being accessed has a protocol of "https". Protocols must match.
Am I right in saying that my local development system cannot be set up to use the https protocol?
This is not only to do with a differing protocol (HTTP on your site vs HTTPS on accounts.google.com), it is also because the domain does not match (and port for that matter), a restriction imposed by the Same Origin Policy.
This policy stops www.evil.com from loading a site such as www.bank.com inside a frameset (or popup window if framing is disabled) and then accessing the DOM. If the DOM could be accessed, this would be a massive security risk as any website could read your private data on another site.
It is possible to allow access by implementing a CORS policy and outputting server side headers to allow other specified domains to read content, however this would be on Google's side in your case. So unless https://accounts.google.com implements a CORS policy, you will not be able to make a client-side variation of the server side flow. Another barrier is that even if CORS was implemented it does not allow access to the DOM. However, you'd be able to retrieve content from another domain, protocol or port via AJAX calls. The target site would also have to output the Access-Control-Allow-Credentials: true header in order for authentication credentials (i.e. cookies in this case) to be sent with the request and the response read by your domain.
Can I use https for local development?
To answer your original question, the answer is yes. This can be a self-signed certificate for most purposes and it will not affect this particular error message in your browser (as you, as the browser user has chosen to accept and trust the certificate).
I was wrong in saying that
my local development system cannot be set up to use the https protocol
It can! Simply by using self certification SSL.
If I have a SITEA writing a cookie to my browser, can SITEB write code to access the cookie or are cookies hidden from websites that didn't create them ?
My answer to that was that YES, SITEB can read the document.cookie and if he knows what's the cookie name, it can access it. Was I right ?
Regarding the second questions, I don't think there are Server Side cookies other than SESSIONS. Am I right?
Cookies are usable by both the server and the client. Cookies can only be read by the website the domain that creates them; you can use sub-domains domains, url paths. Cookies are generally considered insecure if used from the client side, and should not be used to hold sensitive data if accessed from the client side. The server can encrypt information and store it in the cookie as long as the encryption is done on safe manner on the server. Using cookies are a good way of avoiding the use of a session server, and if you do not save sensitive data they are a good way to store state in a web application. Although they can be more challenging than other session mechanisms, the do work on both the client and the server.
Advertising products like double click use cookies to track a monitor user activity, which is how ads follow you from site to site.
Third-party and first-party cookies
Cookies are categorized as third-party or first-party depending on whether they are associated with the domain of the site a user visits. Note that this doesn’t change the name or content of the actual cookie. The difference between a third-party cookie and a first-party cookie is only a matter of which domain a browser is pointed toward. The exact same kind of cookie might be sent in either scenario.
https://support.google.com/adsense/answer/2839090
Cookies are accessible on the basis of domain. This is the basic inherent feature of any browser otherwise it would have been very easy for companies to snoop on each other's users.
If Site A has domain .xyz.com then any website having the same domain can access the cookies. But if any site has domain xyz.com (dot missing) it cant access any other domain's cookies.
Also the http request send to server will contain cookies of the domain from which it is sent.