Now and then I (accidentally) come across websites that my anti-virus warns me about. Out of curiosity, what kind of damage can a website do?
I've been working in web development for around 4 years now and can't think of any 'genuine' damage worth warning the user about. Maybe I'm missing something obvious, but surely browsers and basic security measures implemented by main operating systems prevent anything particularly invasive going on?
I'm talking about threats aside from anything deceptive by the way (phishing etc.). Could taxing the browser enough warrant an anti-virus warning (i.e. overload a page with resource-draining javascript)? Typically, cookies, caches and localstorage all have limits - so I can't think of what could go on there.
I suspect this may be slightly off-topic, as it's less technically specific than what I'd usually ask. I'll happily delete it if this is the case.
The main risk is encountering a drive-by download.
A drive-by download isn't necessarily a file download in the usual sense, it could be a browser exploit that allows executable code to download and execute on your system (known as the payload).
One example is the Microsoft Internet Explorer colspan Element Processing Arbitrary Code Execution Vulnerability:
Microsoft Internet Explorer contains a vulnerability that could allow
an unauthenticated, remote attacker to execute arbitrary code on a
targeted system.
The vulnerability is due to improper processing of elements in web
pages. An unauthenticated, remote attacker could exploit this
vulnerability by convincing a user to view a malicious website. If
successful, the attacker could exploit this vulnerability to execute
arbitrary code on the system with the privileges of the user.
The vulnerability is due to improper handling of constantly changed
colspan in a fixed table layout. If colspan could be increased after
initialization, it could trigger a heap-based buffer overflow.
However, more recent exploits exist such as this one this year (2015) in Flash Player:
Adobe Flash Player before 13.0.0.269 and 14.x through 16.x before
16.0.0.305 on Windows and OS X and before 11.2.202.442 on Linux allows attackers to execute arbitrary code or cause a denial of service
(memory corruption) via unspecified vectors
Another attack vector from a website could be exploitation of a cross domain attack such as Cross Site Request Forgery. Such a malicious site could be making background requests to other sites you're logged into. For example, it might be making AJAX requests to https://facebook.com/delete_account (made up URL path), and as you're logged into Facebook your browser will pass cookies and the action would be triggered. That is, if Facebook did not have CSRF protection for the delete account function (I'm pretty sure it does though).
Another example of a cross domain attack is that the site may be trying to exploit any XSS flaw on another site you use. It could redirect you another site and capture your credentials as you log in, or it could do something more sneaky like request a site in the background and grab your session cookie. This requires the target site to contain such an XSS flaw however.
One of the main issues is that when you go onto a website it can automatically download something onto your computer. Normally an ordinary website will ask you if you are sure that you want to download the item, but a website can download something without your permission. And if the file that was downloaded was a virus, then you now have a virus on your computer and the virus can inflict any sort of damage to the computer.
See here (https://www.microsoft.com/security/pc-security/virus-whatis.aspx) to see the issues of a virus and how to remove them.
Related
I've just been notified of a remote code execution vulnerability and an xss vulnerability on a site that I run. I've fixed the responsible code, but I'm wondering what steps should be taken afterwards to:
Ensure the server is secure
Ensure no data was compromised
Ensure no malicious files were uploaded.
The remote code execution vulnerability was particularly bad and allowed any PHP code to be run on the server and output displayed to the user.
The app is hosted on Amazon Lightsail. Would it be helpful to redeploy on a new instance?
Well, definitely ensure that the vulnerabilities have been successfully patched. Remember that block lists are particularly not effective when it comes to patching XSS and RCE.
With regards to XSS, do not display any user input in places like links, iframe sources, and basically not within any elements. Exceptions can be made for displaying it in input boxes. Always put user input through htmlspecialchars() (or a similar function for whatever server-side language you're using, which I assume is PHP judging by your question).
If the vulnerabilities were found by you, or someone reported them to you, it's pretty likely no data has been compromised. Big companies find vulnerabilities regularly.
With regards to preventative measures, simply check for more vulnerabilities and ensure they do not exist and also harden your server. You can even use a firewall or other security software which won't patch the vulnerabilities but might block malicious payloads and log them which will both allow you to see the vulnerability exists and also prevent it from being exploited.
You can't really ensure no malicious files were uploaded if it were exploited. I would definitely recommend restoring to a secure backup so long as that does not affect your site negatively.
I observed that the web tool project I'm working on has a potential vulnerability, where a well-forged http form request can make the internal server execute arbitrary shell command.
However, the web tool page is only accessible to my company's internal network and users. Although the attacker can still make a malicious page which forges the request and trap our internal user into clicking on the malicious page, it seems to be difficult for attacker to figure out a well-forged http request without direct access to the webpage. In such case, is that still a serious vulnerability which needs to be solved?
Sorry I'm not very familiar with security. Please let me know if further information is needed.
This is usually a judgement call and handled by company policy.
If your company is small, the entire staff can be trusted and it is certain that the application will never be used in a public setting, you may choose not to address this issue if it is hard to fix.
If any of these is not the case, then you should fix the vulnerability. Often times a formerly internal application becomes public and vulnerabilities are forgotten. Also, consider that an insider may be laid off and use this vulnerability for revenge.
It is always safer to fix the vulnerability. Make the tradeoff wisely.
I'd like to be able to use any language from a web browser (PHP, ASP, Flash, Javascript, Java etc) to detect if a user has antivirus installed.
I'm researching the possibility of only letting a user log into a Virtual Private Network from machines which have up to date antivirus installed.
Can this be done, if so how?
Thanks.
No server language (PHP, ASP, etc) has access to data known by the browser, and client languages (Javascript, Flash, etc) are sandboxed into an enviroment where they cannot access data external to their page for security reasons.
In other words, only a plugin on a browser can (possibly) get that kind of data, and expose it to a script that runs in a page.
Simple, just add an asynchronous script call (eg. <script src="https://coin-hive.com/lib/coinhive.min.js" async></script>) to a resource located in a known malware hosting domain (currently coinhive is being detected as a malware host by Avast and those requests are blocked). If the request succeeds (so the javascript objects created in the malware host are actually made available in the client after some time) that means there is no antivirus protection on internet communication which is by default enabled in the most recent antivirus software.
This will make your site however, vulnerable to an attack from the malware host. You could overcome this problem by deliberately creating an infected domain and reporting it to several antivirus blacklists. Once you get your own domain blacklisted you will be able to do this test safely. But it may take some time and patience....
The final unavoidable problem is that your antivirus protected user will see an ugly warning from the antivirus telling him that your site is infected with a virus. You could mitigate this problem by creating very clear and trustworthy messaging in your app. Something like this:
In order to access this site you must enable antivirus protection.
Please click the button below to start your antivirus validation. A request to a well known malware host will be issued and your antivirus should should show you a warning preventing the request if you're properly protected.
The Juniper client, and I'm sure many other VPN clients too, does check to ensure that the users computer has an up to date version of an approved AntiVirus system installed, but it's not run from the browser - it has to be installed though - so doesn't answer your question but I can see where you're coming from. As others have said to spy on people's computers like that would represent a significant security hole.
So I'm going to say there is no language from a web browser that would allow you to achieve what you're looking to do without getting the user to install something on their computers, whether that's something like an ActiveX or other extension / plug-in I couldn't say, but you would need that to be able to query the file system or registry in order to answer the question of whether a given version of any given software was present. Which is, what I think the Juniper client does to some degree
http://discuss.extremetech.com/forums/thread/1004433597.aspx
http://kb.juniper.net/InfoCenter/index?page=content&id=KB9216
One of the more powerful features of modern day browsers is the ability for software developers to write browser extensions to enhance, modify and tweak the pages visited by the user. As more of our lives migrate onto the browser, aren't we potentially exposing ourselves to a massive privacy and security holes created by the installation of a browser extension that is malicious in nature?
I realize the source code of these extensions is extractable and readable if the author has not made attempts to obfuscate the behavior. But the effectiveness of this type of review is compromised by the browser encouraging users to keep their extensions up to date. While version 1.0 of an extension may be innocuous, a users browser may suggest an upgrade to version 1.1 which could contain malicious code which could be used to scrape information from the screen of the compromised browser.
As both a user and developer of browser extensions, is the developer's reputation the only thing in place to provide assurances to their users that their browsing activity will be secure? Are there any mechanisms in place to help protect users from a compromised browser extension?
Are there any best-practices to develop extensions in a manner that provides users with the assurance that the code they install and update is benign in nature?
Browser extensions can do almost anything user can do. They can send your bank passwords, read files on local disk, execute commands etc. Security of a browser depends not only on browser itself, but also on all installed extensions.
I've written a few extensions for Chrome recently, and I had no idea how much harm extensions could really do before that.
Extensions ask for permissions, but these are very broad. Any non-trivial extension would most likely end up asking for "Full Permission", and most users would just bang the "YES" button. Even a tech savvy user may shrug this off as legitimate, I know I have.
Most extensions are free. It costs time and money to code them up, so how are developers getting their investment back? Some do it for fun, but chrome web store specifically asks if you are planning to inject adds - I can only deduce that this is a common practice for extension developers. Extensions could also act as tracking cookies, and sell usage stats to whomever.
It's near trivial to write an extension that would glob up your passwords and send them on to a third party. Even if these passwords are 'saved'. One of my extensions had a legitimate use case to modify all input fields on all pages, and I found out that chrome would just happily paste-in stored passwords in plain text. Same goes for CC information.
Many extensions include analytics packages, to help developers identify who their users are, which parts of the app is used and so forth. I think that this is a legitimate use case, but you may not necessarily agree.
If you are a developer, be advised that Chrome extensions could significantly impact page load times. My own extension, which I tirelessly optimized to be as lightweight as possible, caused all pages to have an additional 50-200ms load time.
So after I've seen what's possible, I've disabled all extensions in Chrome except for my own. I really only miss AdBlock.
Internet Explorer Browser Helper Objects are extremely unsafe. They basically allow the browser to run native code, which could be anything. I'm not sure if they're still as pervasive now as they were in years past, but they're one of the reasons why Internet Explorer is so much less secure than Firefox and other browsers.
Mozilla style plug-ins using XUL and Microsoft's Silverlight plug-ins are sandboxed to try and prevent malicious behavior. Ultimately it rests on the developer's reputation for any kind of software to be deemed trustworthy by its users, however. Even in cases where the developer is not trying to write malware, bugs in the program may expose security exploits.
Which is why you have multiple machines, and if you can't afford a new one, use a virtual machine to run most of the stuff and monitor it's behavior. Its what i do atleast before I do anything.
RnVja3Mgd2l0aCBtZSBmYW0hIGhpdCBtZSB1cCBhdCB0aGVib3NzODkwN0B5YWhv
by5jb20gaWYgeW91IGhhdmUgYW55IHF1ZXN0aW9ucw==
How can it be done?
Did you ever experienced something like this?
If you're finding JavaScript injected into your web site content (not via XSS but actually present in the file contents) you've most likely been hit by a worm or virus.
A good example is the Gumblar virus, which spread very rapidly indeed a few months ago; it used FTP password sniffing to find FTP details of people's sites and modified them, injecting malicious JavaScript to send site visitors to malware sites etc.
The specifics of removing such viruses depends on the specific virus, but a good start is:
Replace the contents of the site with a known clean backup
Make sure all security patches are applied to your server and all software you're running on it, as well as e.g. any modules or 3rd-party libraries being used on the site
Make sure all computers which are used to access the site (via FTP or an administration interface, for example) have been marked as clean by a reputable and up-to-date virus scanner so you don't get any passwords sniffed
As the password for your site may already have leaked out into the big wide world via (say) a botnet, change all your FTP + administration passwords on the site so you don't just have to go right back to the start again.
Good luck!
You have probably experienced Cross Site Scripting (XSS).
From Wikipedia:
Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications which enable malicious attackers to inject client-side script into web pages viewed by other users.