I have a product that requires sign-in authentication. I use jwt but store that inside cookies (which I know could be a problem once there is an xss vulnerability).
This product is also given to some "other domains" that embed it through an iframe.
I'm curious if there are any security risks that I did not think about in this situation.
E.g. Does the parent, "other domain", have access to my authentication tokens since I use cookies to store my JWT tokens? If the parent has xss vulnerability, then this would automatically imply a vulnerability for me as well?
I have a product that requires sign-in authentication. I use jwt but store that inside cookie (which I know could be a problem once there is an XSS vulnerability)
Storing in Cookie is not a problem Now By using some headers Like sameSite and CSP it is even harder To exploit XSS They can Pop-up alert box but they cannot steal cookies though it gives You the confidence To use it It really depends On How You code a functionality. If you are using frameWorks(like- Jinja, Vue, angular, ejs..etc) There is a very low chance to Attacker To inject code.
This product is also given to some "other domains" that embed it through an iframe
If the parent Domain Having an XSS. then Probably The iFrame also affected To XSS. They Can see the content and send It there domain or There is a Tool called xsshunter.io You can check By testing IT on a Development server. But if You use CSP and Same-site: Lax then it's Not a problem there will be no communication to External Domain other than the Whitelist domain.
If it's vertical privilege From child to parent Then You have a great feature Called sandbox in the iframe.
(no value) Applies all restrictions
allow-forms Allows form submission
allow-modals Allows to open modal windows
allow-orientation-lock Allows to lock the screen orientation
allow-pointer-lock Allows to use the Pointer Lock API
allow-popups Allows popups
allow-popups-to-escape-sandbox Allows popups to open new windows without inheriting the sandboxing
allow-presentation Allows to start a presentation session
allow-same-origin Allows the iframe content to be treated as being from the same origin
allow-scripts Allows to run scripts
allow-top-navigation Allows the iframe content to navigate its top-level browsing context
allow-top-navigation-by-user-activation Allows the iframe content to navigate its top-level browsing context, but only if initiated by the user
it is good Practice To Use JWT in headers But there is No problem At all using It in cookies But using JWt in headers is more secure.
Hope This Help's You!
Related
Given a third-party webpage www.somepage.com handing out specific URLs to subscribed websites in the format of www.somepage.com/site/3ir3jsd - how can I track that a user having an account on www.somepage.com has visited one of the subscribed websites without resorting to cookies / localStorage ?
A standard approach would be to store a cookie for www.somepage.com and add www.somepage.com/site/3ir3jsd via an IFrame. This has several issues as new laws and browser defaults prohibit third-party cookies and local storage to be loaded.
Is there some other mean to achieve this? I see that this is a potential privacy issue and would of course ask for permission to do this and would prefer secure / non-privacy-infringing methods. All major browsers have to be supported which rules out browser extensions too (looking at you Internet Explorer 9-11). Maybe JavaScript? But I don't want the user to have to "login" to my pages service on every subscribed webpage. Storing their session cookie in the first-parties localStorage / cookie is a potential security risk though (which would be needed when using JavaScript + storing their session data).
Another approach I have checked is client certificates but they are poorly supported (read: often unsupported) by mobile browsers and the use-ability of adding them is horribly in most of them too.
This isn't a language specific question, but I am using PHP5.
I am working on a project that has some amount of PII. Legally we are required to secure this data from hacking attempts, and because of that I have been researching best practices for defending common attack types. Obviously all database calls are using parameterized queries, and all data provided by the user is sanitized to prevent injection. I have also implemented sessions and methods to prevent session hijacking.
When it comes to defending against XSS attacks on forms, best practice seems to be to include a hidden input with a form token, then after the post to check the tokens match. There are further ways to make this more secure.
I have imagined one type of attack and haven't found a solution for it. What if a malicious site loads a hidden iframe pointed at my site (eg, view-member.php?id=1234) and because the victim user is logged into my site, their session continues in that iframe. What is stopping this malicious site from iterating through the IDs and ripping the data to get ahold of PII? Should I be creating a unique token for each page view, and checking that token when the page loads?
I am not 100% sure, but assuming my site is using HTTPS, the browser should warn the user and/or prevent the connection. Is that correct? Is that enough security?
In fact, everytime you present a form or any kind of interaction, you should include a randomized, verifiable piece of information that changes every time. This is not for preventing XSS but CSRF: https://en.wikipedia.org/wiki/Cross-site_request_forgery
The main problem is: An attacker can just send automated requests to your input-handling script without going through the "pain" of filling in your form manually (or even visit your page).
However, you won't prevent XSS attacks with this technique, as XSS attacks are mainly user input containing executable code (javascript) that is not filtered by the input validation. So to prevent XSS as well, you should always make sure not to deliver unfiltered user-generated content anywhere.
HTTPS won't help you in either case unless you use client-side certificates that allow access to your website only from trusted clients. HTTPS mainly acts as a transmission scrambler and identity verifier but does not prevent a bot from sending valid (but malicious) data to your form.
Hosting a website in an iFrame does not grant the attacker the permission to read cookies or information from the target page (that would be awful) as long as you follow the same-origin policy: https://en.wikipedia.org/wiki/Same-origin_policy
With this, only domains you whitelist will get access to information hosted on your page.
My web application displays some sensitive information to a logged in user. The user visits another site without explicitly logging out of my site first. How do I ensure that the other site can not access the sensitive information without accept from me or the user?
If for example my sensitive data is in JavaScript format, the other site can include it in a script tag and read the side effects. I could continue on building a blacklist, but I do not want to enumerate what is unsafe. I want to know what is safe, but I can not find any documentation of this.
UPDATE: In my example JavaScript from the victim site was executed on the attacker's site, not the other way around, which would have been Cross Site Scripting.
Another example is images, where any other site can read the width and height, but I don't think they can read the content, but they can display it.
A third example is that everything without an X-Frame-Options header can be loaded into an iframe, and from there it is possible to steal the data by tricking the user into doing drag-and-drop or copy-and-paste.
The key point of Cross Site Attack is to ensure that your input from user which is going to be displayed, is legal, not containing some scripts. You may stop it at the beginning.
If for example my sensitive data is in JavaScript format, the other site can include it in a script tag
Yep! So don't put it in JavaScript/JSONP format.
The usual fix for passing back JSON or JS code is to put something unexecutable at the front to cause a syntax error or a hang (for(;;); is popular). So including the resource as a <script> doesn't get the attacker anywhere. When you access it from your own site you can fetch it with an XMLHttpRequest and chop off the prefix before evaluating it.
(A workaround that doesn't work is checking window.location in the returned script: when you're being included in an attacker's page they have control of the JavaScript environment and could sabotage the built-in objects to do unexpected things.)
Since I did not get the answer I was looking for here, I asked in another forum an got the answer. It is here:
https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.security/9U6HTOh-p4g
I also found this page which answers my question:
http://code.google.com/p/browsersec/wiki/Part2#Life_outside_same-origin_rules
First of all like superpdm states, design your app from the ground up to ensure that either the sensitive information is not stored on the client side in the first place or that it is unintelligible to a malicious users.
Additionally, for items of data you don't have much control over, you can take advantage of inbuilt HTTP controls like HttpOnly that tries to ensure that client-side scripts will not have access to cookies like your session token and so forth. Setting httpOnly on your cookies will go a long way to ensure malicious vbscripts, javascripts etc will not read or modify your client-side tokens.
I think some confusion is still in our web-security knowledge world. You are afraid of Cross Site Request Forgery, and yet describing and looking for solution to Cross Site Scripting.
Cross Site Scripting is a vulnerability that allows malicious person to inject some unwanted content into your site. It may be some text, but it also may be some JS code or VB or Java Applet (I mentioned applets because they can be used to circumvent protection provided by the httpOnly flag). And thus if your aware user clicks on the malicious link he may get his data stolen. It depends on amount of sensitive data presented to the user. Clicking on a link is not only attack vector for XSS attack, If you present to users unfiltered contents provided by other users, someone may also inject some evil code and do some damage. He does not need to steal someone's cookie to get what he wants. And it has notnig to do with visiting other site while still being logged to your app. I recommend:XSS
Cross Site Request Forgery is a vulnerability that allows someone to construct specially crafted form and present it to Logged in user, user after submitting this form may execute operation in your app that he didin't intended. Operation may be transfer, password change, or user add. And this is the threat you are worried about, if user holds session with your app and visits site with such form which gets auto-submited with JS such request gets authenticated, and operation executed. And httpOnly will not protect from it because attacker does not need to access sessionId stored in cookies. I recommend: CSRF
Why do browsers apply the same origin policy to XMLHttpRequest? It's really inconvenient for developers, but it appears it does little in actually stopping hackers.
There are workarounds, they can still include javascript from outside sources (the power behind JSONP).
It seems like an outdated "feature" in a web that's largely interlinked.
Because an XMLHttpRequest passes the user's authentication tokens. If the user were logged onto example.com with basic auth or some cookies, then visited attacker.com, the latter site could create an XMLHttpRequest to example.com with full authorisation for that user and read any private page that the user could (then forward it back to the attacker).
Because putting secret tokens in webapp pages is the way to stop simple Cross-Site-Request-Forgery attacks, this means attacker.com could take any on-page actions the user could at example.com without any consent or interaction from them. Global XMLHttpRequest is global cross-site-scripting.
(Even if you had a version of XMLHttpRequest that didn't pass authentication, there are still problems. For example an attacker could make requests out to other non-public machines on your intranet and read any files it can download from them which may not be meant for public consumption. <script> tags already suffer from a limited form of this kind of vulnerability, but the fully-readable responses of XMLHttpRequest would leak all kinds of files instead of a few unfortunately-crafted ones that can parse as JavaScript.)
Suppose I have a web app that I want to embed into any other site using an iframe. The iframe references my site and operates independently of the hosting web page.
Well, the browser considers the iframe to be a third party site, therefore its session cookie is considered a third party cookie. Some methods exist to make the browsers happy (e.g. P3P header), but it's still possible the user would have third party cookies disabled entirely. If so, then session cookies can't persist in an iframe.
What are good methods for persisting a session in an iframe on a third party site?
I have faced a similar problem you have here. There is a workaround (Will not work if your intention is to track user behavior across sites).
i. Place a first party persistent cookie on the domain where your iframe is to be hosted. (This can be done using JavaScript).
ii. Dynamically inject the iframe and pass across the value of the cookie to your site.
iii. If you intent to track user behavior across sites, modify the above code so that you use third party cookies when the browser allows, else switch you use the above approach.
I haven't come across any other way to work around this. If you find a more acceptable solution do let me know.
My intent is to track a session within the iframe, so that clicks and reloads maintain state. It's not necessary to link sessions between the iframe and the hosting site.
The best I could come up with is cookie-less sessions. It's a bit manual, but with this site running PHP, I just need to ensure the querystring always contains "PHPSESSID=x" and it'll automatically attach to that session id.