Can my system get infected with something by visiting a website using phantomJS? I don't know/trust the website I'm visiting. And if so, how to prevent it/avoid damage?
It is not technically impossible.
PhantomJS uses WebKit as its web browser engine (the same as Safari and many other browsers including earlier versions of Chrome), and it can be compiled against any version of WebKit. This means WebKit is used for parsing and internally rendering a web page.
If the version of WebKit that your version of PhantomJS uses is vulnerable, so will be PhantomJS. If there is something like a buffer overflow or similar remote code execution in WebKit, that can probably also be exploited in PhantomJS too, potentially resulting in a malicious website being able to run code on your computer. These types of flaws (with severity similar to an exploitable remote code execution) are not very frequent, but they happen sometimes. Note that all other, lower risk vulnerabilities of WebKit also affect any version of PhantomJS that is compiled with the vulnerable version of WebKit. What makes this more relevant is that WebKit is used by many projects, so finding and exploiting WebKit vulnerabilities may be worthwhile for an attacker.
PhantomJS itself may also be vulnerable, but the real dangerous thing is parsing the code written by somebody else when visiting the website, and that's done by WebKit. Exploiting flaws in other supporting code in PhantomJS via a visited website would I think be more difficult. Not saying that it's impossible, but the likelihood would I think be low.
As for how to prevent this... The most important thing would be to use a version of PhantomJS that is compiled against a very recent version of WebKit. If there is no known vulnerability for either the WebKit version or the PhantomJS version, you're kind of good to go (but there can always be zero-days of course).
If you are really worried, you could run PhantomJS in isolation. You could set up something similar to a chrooted environment, or an entire dedicated virtual machine. In the latter case the attacker would have to compromise the hypervisor in a completely separate attack, which is probably not impossible, but can be hard, and is very different from any flaw exploited in PhantomJS.
Of course it also depends on what you want to protect against. If you are worried about a compromise of the client running PhantomJS, running it in isolation might be adequate for your scenario. If PhantomJS is part of a larger application and you are worried about the attacker being able to access data in that particular application, you obviously cannot run PhantomJS in isolation from the actual application with the data, so a VM would then not help.
So the bottom line is, yes, it can happen, but it's not very likely, and what countermeasures you need depends on a few things including the risk (what you can lose), and your threat model (what you want to protect against).
Related
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.
I don't usually post in forums because normally I can find any answer I need using Google. However every search that I am running is giving me very specific results, such as buffer overflow vulnerabilities that already exist for a specific game or system which is not what I need.
I have a home network including Windows Server 2008 R2 and my son wants to start a Minecraft server which of course I want to give him full access to so he can learn. However, I know that every game is "moddable" and he uses custom maps and the like in a lot of his games.
My concern is that I am going to create security risks on my network based on inexperienced programming. Will giving him the ability to install and create mods on my server potentially open up vulnerabilities (outside of the open Minecraft ports) due to the possible inexperience of people actually writing the mods? Or do mods just simply not work that way and I can't find an answer to my question because it's retarded and no one actually programs a mod lol?
Depends on the way the mod system works for the game, and whether the game itself is sandboxed. Importantly, no software is perfectly secure. You have to decide what level of security and reliability you are happy with.
There are several ways a mod could expose a vulnerability:
The game could allow the mod access to an inappropriately permissive set of actions, such as access to the filesystem. This can include the developer not sandboxing the mod properly.
The mod could exploit a vulnerability in the game's API to access actions the game developer didn't intend. This would be due to a bug in the API.
The mod could exploit a vulnerability in the language engine (for example, Java has a long history of security vulnerabilities).
The mod itself could be vulnerable to attack, and could be made to launch one of the attacks above.
If the mod system is script or VM based, such as Lua, JavaScript or Java, I would feel relatively safe installing mods (so long as the game has a well implemented API/sandbox), because exploits 2-4 are relatively unlikely.
(My understanding of native code mods/plugins is limited, but I'm pretty sure you MUST trust a native mod if you want to run it. Even if you do, it might still be exploitable. )
My understanding of minecraft mods is that they are written in java. My feeling about the Mojang guys is that they know what they're doing, so I'd be surprised if their mod API isn't exceptionally well designed and implemented. Having said that, installing mods necessarily introduces a security risk.
If this risk is unacceptable, you can reduce it by introducing depth to the system. Why not, say, run your minecraft server in a virtual machine, with limited access to the network (only required ports, for example)? That way the impact of vulnerabilities is reduced greatly.
I'd recommend creating a Ubuntu VM on VirtualBox (because they're both free as in beer), but you could install it on whatever OS you're comfortable with.
Buffer overrun vulnerabilities are associated with programming languages that permit unchecked memory access. Minecraft is written in Java, a language which is not susceptible to buffer overruns, so a pure-Java mod would be very unlikely to exhibit anything resembling this kind of vulnerability.
Naturally programs in Java can still be vulnerable to other kinds of security issue, either against the game itself (eg there have been game-account login exploits against Minecraft servers) or against the server (I'm not aware of any known cases of this for Minecraft, but it's always possible). The usual mitigations for running servers apply, for example lock down network access to good IPs if possible, run server as limited user and so on.
I would like to start a community discussion. As per my question, when do you decide to stop supporting older browsers?
I've nearly completed the development of a large personal application. It uses a lot of HTML5, CSS3 and JavaScript. If I were to support older browsers, I would estimate that it would increase my front end work load by at least 50%. And to be frank, I don't want to support the older browsers. From a business point of view, one could argue that if I don't, I could lose revenue. I disagree. I feel that the customers who use older browsers wouldn't be the customers I would want anyway - they would be the ones giving me more work as I'd have to fix compatibility problems in my application to work with their old browser or have to continually tell them to upgrade their browser. If the web is to move on, then people need to stop supporting the older browsers, however, I do see that the tide is slowly starting to turn towards this.
Recently, IE6 was pronounced dead. When can we safely say that IE7 and IE8 or indeed Firefox 3 can longer be considered as 'important' enough to support?
Furthermore, I hear a lot of people say on this site "make sure it degrades gracefully so it'll still work with browsers that don't have JavaScript support"? What kind of browsers now don't have JavaScript support? Mostly old phones and if these old phones don't support JavaScript then I highly doubt that they will parse the HTML correctly either. I also have a Sencha touch mobile version of my application. Am I going to make a WAP version of it to support older phones? No. It's a rich web app. That's how it has designed to be and that's how I intend for it to stay.
I rather like Apple's approach: If you upgrade your OS, don't expect your apps from the previous of the OS to work with the new one. Yes, it can be a frustration, but it means there is less of a mess overrall and people are forced to upgrade to move along with the times.
It works the same way for new web apps, if I want to keep them clean, quick and efficient, I need to stop hacking the code to support legacy software and if users don't like it, they can move on from my site or join the rest of us and upgrade their browser and have a better web experience.
I don't want this to come across as arrogant, but I am genuinely interested in your opinions when you consider enough is enough and only support recent browsers.
For me, I have always assessed the users who would be using it. I think in the end, it is impractical to support every single browser and its version under the sun.
As a baseline, I always ensure that the application works fine in IE8 and the latest version of Firefox. IE8 is pretty decent, so there usually isn't much work required to get it working. As most versions of Firefox and Chrome tend to get auto updated, I just test in Firefox Latest, Firefox 3.Latest and the latest version of chrome.
For example, if I am designing an application to be used by tech-heads, I wouldn't really care much about IE7 and below, or old versions of Firefox and Chrome.
However, if I am designing something that will be used internally and there are certain browser requirements, then I will make sure that the app works perfectly in those browsers (i.e. the dreaded IE6 and IE7).
As IE8 is the "final" version on Windows XP, I think it would be quite beneficial to ensure that things work decently in IE8 at least.
Also, since Facebook and GMail has dropped support for IE7 and below and older versions of other browsers, I think it's safe to say that we can ignore those versions too.
As for javascript, I think it is impractical to build something that works exactly the same without javascript. I think it is a good idea to gracefully degrade, so that certain things might not be avaliable for the user, but they can still use the app to a certain extent.
However, in certain cases, the whole app would not be able to work without javascript (or a non-javascript experience would be next to useless), then telling the user to enable javascript is probably a good idea. This is implemented in apps like Facebook and Google Docs. See this excellent blog post for some debate.
So, in summary:
Develop for "modern browsers", IE8+, FF3.latest and the latest FF, latest Chrome and Opera.
Support other browsers if the development/client requirements exist.
Look at what the big boys (facebook and gmail) are doing in terms of browser support. If they can afford to drop support for browser x and we are developing an app targetted towards general consumers, then we can afford to drop support for browser x too.
I agree with you on the most part that it is a pain to support older browsers and I think that creating web applications that are supported on older browsers such as IE6 and IE7 should be stopped because it is our duty as developer's to help the web advance even further.Furthermore Google has dropped support for every IE browser under IE8 and these in my agenda means that the browser is as good as dead and I can safely stop to create websites for it.
IE8 is a decent browser and is still very widely used even if it's usage is being dropped at an increasing rate : browser usage statistics ; I still think that you should develop for it at least a year from now when hopefully it's usage will be to small to matter
Firefox ,Safari,Chrome and Opera have auto updates witch popup to the user every time a new version is released so most of the times I don't bother checking for older versions how my websites work.
But about the graceful degradation of your websites I still think you should try as much as possible to make your websites work even if you have Javascript disabled because not all users have old browsers that don't support Javascript but there are those who keep it turned off for various reasons
Okay, here's a complicated one I've been breaking my head over all week.
I'm creating a self service system, which allows people to identify themselves by barcode or by smartcard, and then perform an arbitrary action. I run a Tomcat application container locally on each machine to serve up the pages and connect to external resources that are required. It also allows me to serve webpages which I then can use to display content on the screen.
I chose HTML as a display technology because it gives a lot of freedom as to how things could look. The program also involves a lot of Javascript to interact with the customer and hardware (through a RESTful API). I picked Javascript because it's a natural complement to HTML and is supported by all modern browsers.
Currently this system is being tested at a number of sites, and everything seems to work okay. I'm running it in Chrome's kiosk mode. Which serves me well, but there are a number of downsides. Here is where the problems start. ;-)
First of all I am petrified that Chrome's auto-update will eventually break my Javascript code. Secondly, I run a small Chrome plugin to read smartcard numbers, and every time the workstation is shutdown incorrectly Chrome's user profile becomes corrupted and the extension needs to be set up again. I could easily fix the first issue by turning off auto-update but it complicates my installation procedure.
Actually, having to install any browser complicates my installation procedure.
I did consider using internet explorer because it's basically everywhere, but with the three dominant versions out there I'm not sure if it's a good approach. My Javascript is quite complex and making it work on older versions will be a pain. Not even mentioning having to write an ActiveX component for my smartcards.
This is why I set out to make a small browser wrapper that runs in full screen, and can read smartcard numbers. This also has downsides. I use Qt: Qt's QtWebkit weighs a hefty 10MB, and it adds another number of dependencies to my application.
It really feels like I have to pick from three options that all have downsides. It really is something I should have investigated before I wrote the entire program. I guess it is a lesson learnt well.
On to the questions:
Is there a pain free way out of this situation? (probably not)
Is there a browser I can depend on without adding tens of megabytes to my project?
Is there another alternative you could suggest?
If you do not see another way out, which option would you pick?
I'm looking for an open source headless browser to run on a FreeBSD shared Web server, which can do reasonably accurate rendering of current HTML/CSS/JS.
As I'm not very skillfull with Unix/servers and don't have root access, this should have no dependencies that would not be installed on a typical Apache shared Web hosting server (ruling out Java and HtmlUnit I believe), and should ideally even be pre-compiled for FreeBSD.
I guess I need a command-line and/or PHP-accessible interface (I'm not too clear on how any of that will work).
Please respond to this question if:
you're already familiar with this new trend in Web dev of rendering things server-side with headless browsers (e.g. page previews, Google-friendly AJAX indexing, etc.)
and you have some software to recommend for my needs
Thanks
I like lynx, it's a bit limited but unbelievably fast.
Maybe http://phantomjs.org/ is worth to have a look at.
Another way is to remote control the real browser using for example
http://www.seleniumhq.org/