In the documentation for phantomjs, there is an option to turn off web security and allow XHR (cross domain requests).
Does this present a security risk to a user if you are filling forms with credentials such as usernames and passwords and then downloading screenshots with casper/phantom?
Maybe.
Allowing cross domain XHR opens up a few attacks. E.g. see https://stackoverflow.com/a/7615287/841830. See also Is CORS a secure way to do cross-domain AJAX requests?
But this tends not to come up with the normal use cases for Phantom: whether you are testing your own web site, or screen-scraping, you tend to go to pre-decided URLs and links, and are not sending secret information, and are not going to be tricked by a new and suspicious link. You are unlikely to be logged into your bank, or Facebook, while testing your site or scraping google search results. (BUT, if you are scraping google pages that force you to sign into Google first, be a bit more careful - perhaps set up a dedicated gmail account just for your scraping.)
So, in summary, the attacks are a bit more obscure and unlikely, compared to a normal desktop browsing session, but they are still there, so only use --web-security=no when your script otherwise will not work.
Related
I am developing a MERN app, where users share things with a link to access those things.
So these things get displayed to other users, and they can click on them, and they get redirected to that link.
This doesn't seem secure as some users can post things with malicious links.
Is there a way to verify that a link is secure and so validate the thing before it gets posted?
This isn't possible in an automated way. Links don't include any information about themselves other than the URL they point to.
You need a list of "malicious" URLs to compare against in order to achieve this. There are services that provide such databases. But this is a never-ending game of cat-mouse.
For example, if I have a malicious website, I don't have to share the URL to my website directly, I can use URL shortener service (bitly for example) that then redirects users. This way, I easily circumvented your protection.
That's the reason browsers have their own "malicious websites" list, since they have access to the final URL you're visiting.
In short: no, there's only limited protection you can offer.
The best you can do is warn the users they're leaving your site, like Discord or Facebook do (and they do that because they can't solve this problem either).
I ask here instead of https://security.stackexchange.com/ because I dont think this question is on a professional level.
I just saw something weird on my bank's website, they are fetching an image from another domain, using http instead of https , on firefox it raises a security "mixed content" alert, on chrome it just shows up an alert on the security tab.
This is the site: https://www.bancoprovincia.com.ar/Principal/BipPersonal
The unsafe content (an image) happens to be on the page just before the user logs in to his home banking, I was worried that some attacker could intercept the content and replace it with something that could be a security risk.
Any chance this is a security risk for the bank and it's clients?.
It's not a direct vulnerability, but still bad practice.
Some risks that come to mind:
An attacker having access to users' connections (man in the middle) could replace the image with a malicious one, exploiting potentially zero-day (as yet unknown) flaws in browser or operating system image processor libraries. This could lead to remote code execution on the client.
Replacing the image could also be used to facilitate phishing. The malicious image could tell the user to call a phone number because of some kind of a problem, etc.
It is an information leak. An attacker may receive information about users browsing to the bank website, also if the image is in a header included on all pages, they may receive information about what the user does. This is inherently the case for every external site that has its images linked even over https, but over http this also applies to any MitM attacker.
It is a potential availability problem. If the image on the external site times out (waits too long to download), the page will not load for some time in some browsers and an attacker could exploit that. However, this I think is not affected by the image being served on plain http, it would affect an externally linked https image as well I think.
It's also a very bad practice, because instead of strengthening good security practices in users like always checking browser indications of a secure website, it is telling them that it's ok if there are warnings. It is not.
I have a website protected by basic auth, so when someone hits it, they get a standard username/password box. This website is accessed often from shared computers.
Is there any way to prevent the various "Remember my Credentials" functionality on browsers? I would like to prevent any browser from saving this username/password in any client-side repository.
I realize this is purely a function of the browser, but is there any commonly-accepted HTTP header or any other method of asking a website not to do this?
The answer is no. I'm really sorry but even if you could do this how would you stop an independent add-in from scraping web sites for username and password boxes and then storing that information.
Even if this were possible in code it could be easily circumvented by simply ignoring any directives you give. Thus rendering such headers pointless.
As stated before it is not possible to circumvent a browser feature it could easily save the credentials before it sent the POST thus stopping anything on the server from preventing it being cached.
I'm in the process of making a portal website and I wanted to include an iframe which would route people to an intranet. Is there any downsides to this as far as security is concerned?
I think that maybe there's a misunderstanding on your side regarding the function of IFrames: An <iframe> will not route anything. It just tells the user's browser which URL to fetch and show inside it. This means that
People need access to the intranet to actually load the contents of the <iframe>, which might not be what you expected.
It's not a security risk per se.
It is no more or less secure than giving those people direct web access to that intranet.
If you really want to know whether something is "secure" or not, you need to specify the types of threat that you need to protect against, what your tolerance is for breaks in that security, and what additional mechanisms that you have taken to secure your site (for example password authentication, NTLM, SSL, etc).
Regarding cross-site request forgery (CSRF) attacks, if cookies are most used authentication method, why do web browsers allow sending cookies of some domain (and to that domain) from a page generated from another domain?
Isn't CSRF easily preventable in browser by disallowing such behavior?
As far as I know, this kind of security check isn't implemented in web browsers, but I don't understand why. Did I get something wrong?
About CSRF:
On wikipedia
On coding horror
Edit: I think that cookies should not be sent on http POST in the above case. That's the browser behavior that surprises me.
Why wouldn't the browser send cookies?
Site A (http://www.sitea.com) sets a cookie for the user.
User navigates to site B (http://www.siteb.com). Site B features integration with site A - click here to do something on site A! The users clicks "here".
As far as the browser can tell, the user is making a conscious decision to make a request to site A, so it handles it the same way it would handle any request to site A, and that includes sending site A cookies in the request to site A.
Edit: I think the main issue here is that you think there is a distinction between authentication cookies and other cookies. Cookies can be used to store anything - user preferences, your last high score, or a session token. The browser has no idea what each cookie is used for. I want my cookies to always be available to the site that set them, and I want the site to make sure that it takes the necessary precautions.
Or are you saying that if you search yahoo for "gmail", and then click on the link that takes you to http://mail.google.com, you shouldn't be logged in, even if you told gmail to keep you logged in, because you clicked on the link from another site?
It isn't that a browser is sending the cookie to or from an outside domain, it's the fact that you're authenticated and the site isn't validating the source of the request, so it treats it as if the request came from the site.
As far as whether a browser should disallow that... what about the many situations where cross-site requests are desirable?
Edit: to be clear, your cookie is not sent across domains.
I don't know that there's much the browser can do in that situation since the point of an XSRF attack is to direct the browser to another point in the application that would perform something bad. Unfortunately, the browser has no idea whether or not the request it's being directed to send is malicious or not. For example, given the classic example of XSRF:
<img src="http://domain.com/do_something_bad" />
it's not apparent to the browser that something bad is happening. After all, how is it to know the difference between that and this:
<img src="http://domain.com/show_picture_if_authenticated" />
A lot of the old protocols have big security holes -- think back to the recently-discovered DNS vulnerabilities. Like basically any network security, it's the responsibility of the end-points; yeah, it sucks that we have to fix this ourselves, but it's a lot harder to fix at the browser level. There are some obvious ones (<img src="logoff.php"> looks damn fishy, right?), but there will always be edge cases. (Maybe it's a GD script in a PHP file after all.) What about AJAX queries? And so on...
The cookies for a site are never sent to another site. In fact, to implement a successful CSRF attack, the attacker does not need to have access to these cookies.
Basically, an attacker tricks the user, who is already logged in to the target website, into clicking a link or loading an image that will do something on the target site with that user's credentials.
I.e., the user is performing the action, and the attacker has tricked the user into doing so.
Some people have said they don't think there's a lot the browser can do.
See this:
http://people.mozilla.org/~bsterne/content-security-policy/origin-header-proposal.html
It's an overview of a proposal for a new HTTP header to help mitigate CSRF attacks.
The proposed header name is "Origin" and it's basically the "Referer" header minus the path, etc.