As a security measure, I want to hide the technology stack I am using on my server. What are effective ways to do this? I thought about
1) Use mod_rewrite or Rewrite Module to hide any page extensions like .php or .aspx
2) Turn off all error reporting
1b) use mod_rewrite to serve a misleading extension on purpose, like disguising a php page as aspx
2b) Throw misleading errors to go with 1b), making my php pages display asp-like errors.
This is an impossible task. You will have to modify the entire stack, in which case you will have just created new buggy versions that you now have to keep in sync with vendor's versions.
There's literally no way to do this without making your site less secure.
You can do lame stuff like remove X-Powered-By, or change the session generation scheme if it's using something like ASP or PHP which has a known one. The fact is it's not going to stop anyone who actually wants to know what you are running.
For basic examples (it goes much deeper than this), some web servers will accept any header, so I can say GET LOLOLOL HTTP/1.1 and it will still work. Some stacks will keep the session alive, some wont. You can also see what features are on the stack, since there are just so many on the web and there's no way on earth any stack supports the exact same set.
Don't show accurate page extensions
Don't use standard error pages
Make sure the web server and application layer (ASP.NET, PHP et al) hide their presence in browser headers)
If your error pages do anything dynamic, assume that this can fail somehow and have a set of static html pages you can serve that aren't the web servers default ones
Make sure all of our technolog stacks are configured to not show stack traces on any error pages served to machines other than the local server. If for some reason all your custom errors fail then the user may see the technology stack, but they won't have a window into the underlying code
You can add fake Server: and/or X-Powered-By headers to the response, pretending that it was generated by a different server. (Or, Server: My Unhackable Server)
Related
I asked this question a little over a week ago on the Atom forums (link below), and didn't receive a response, so I am reposting it here in the hopes that someone may be able to provide insight on my problem.
Recently, I have taken up an open source project which uses Electron as it’s front-end. This project has two requirements: it must be cross-platform, and it must have an embedded web browser (which should be able to browse the web and render content like a typical browser). Considering the rather large footprint Electron has already netted my application, it seems like a bad idea to attempt to use another embedded web framework alongside it. So, in the interest of simplifying my project and retaining the UI built on top of Electron, I am looking into using Electron itself as the web browser. Here’s where I’ve come into a problem.
In a security page for Electron’s documentation, it is explicitly stated that,
it is important to understand … Electron is not a web browser
This quote comes within the context that Electron–or rather the code running on top of it–carries the unique ability to interact with the user’s operating system, unlike typical web applications. The page goes on to say,
displaying arbitrary content from untrusted sources poses a severe security risk that Electron is not intended to handle
At this point, I was tempted to give up on the idea of using Electron as an inbuilt browser, but further down on that same page, you can find another very interesting tidbit:
To display remote content, use the <webview> tag or BrowserView , [and] make sure to disable the nodeIntegration and enable contextIsolation
Link: https://electronjs.org/docs/tutorial/security#isolation-for-untrusted-content
First, in regard to using webviews, Electron’s own documentation recommends outright avoiding them:
Electron’s webview tag is based on Chromium’s webview , which is undergoing dramatic architectural changes. This impacts the stability of webviews , including rendering, navigation, and event routing. We currently recommend to not use the webview tag and to consider alternatives, like iframe , Electron’s BrowserView , or an architecture that avoids embedded content altogether.
Link: https://electronjs.org/docs/api/webview-tag
Seeing as though I cannot avoid embedded content, I opted to look into using a BrowserView, but what I found was not very motivating either. The advice, as it stands, is to do two things:
disable nodeIntegration
enable contextIsolation
After looking at the security and best-practices page, I will also append the following steps:
deny session permission requests from remote content (webcam, microphone, location, etc.)
catch webview elements in creation and strip default privileges
disable the creation of new windows
disable the remote module
That is a fair amount of steps to undergo in securing external content. Not to mention, there were several additional warnings scattered through the best practices page such as the following:
(On verifying webview options before creation)
Again, this list merely minimizes the risk, it does not remove it. If your goal is to display a website, a browser will be a more secure option.
Link: https://electronjs.org/docs/tutorial/security#11-verify-webview-options-before-creation
(On disabling the remote module)
However, if your app can run untrusted content and even if you sandbox your renderer processes accordingly, the remote module makes it easy for malicious code to escape the sandbox and have access to system resources via the higher privileges of the main process.
Link: https://electronjs.org/docs/tutorial/security#15-disable-the-remote-module
Not to mention, upon navigation to the BrowserView page, the whole class is listed as experimental.
This all isn’t even to mention the added attack surface created by Electron, such as a vulnerability in the webview component just last year: CVE-2018-1000136
Now, taking into account all of the above, numerous developers have still opted to create web browsers that routinely consume external and uncontrolled content using Electron.
Browser’s using Electron (linked directly from Electron’s website):
https://electronjs.org/apps/wexond
https://electronjs.org/apps/dot
https://electronjs.org/apps/beaker-browser
To me, it seems irresponsible to submit users to the above security implications as a trade-off for convenience.
That being said, my question is: can you safely, to the point at which you could ensure the integrity of your users, implement web browsing capabilities for uncontrolled content using Electron?
Thank you for your time.
Link to the original post:
https://discuss.atom.io/t/security-implications-in-electron-as-a-web-browser/70653
Some ideas that don't fit into a comment box:
[the project] must have an embedded web browser
So I presume then that this project isn't just a web browser. There's other content there that may have access to Node, but you just want the embedded-web-browser portion of it to be sandboxed appropriately, right?
Regarding the comments about <webview>, yes, it is considered unstable and Electron recommends using a BrowserView instead. I don't think that the fact that it's marked as "experimental" should necessarily deter you from using it (especially considering that the Electron team is recommending it [though maybe as the best of two evils]).
Experimental doesn't imply it's unstable. It can just mean that the Electron team is experimenting with this approach, but this approach may change in the future (at which point I would expect Electron to provide a transition path forward). Though this is one possible interpretation and ultimately Electron would have to comment on this.
The advice... is to do two things:
disable nodeIntegration
enable contextIsolation
I would also make use of the sandbox option inherited from BrowserWindows. BrowserView's docs on the constructor options say:
webPreferences Object (optional) - See BrowserWindow.
which tells me that BrowserView accepts the same options as BrowserWindow.
You would set it up like so:
new BrowserView({ webPreferences: {
sandbox: true,
nodeIntegration: false,
contextIsolation: true,
preload: "./pathToPreloadScript.js"
}});
See more information about this approach here. The preload script is what would expose some Node IPC APIs to the sandboxed content you're loading. Note the Status section at the bottom, which says:
Please use the sandbox option with care, as it is still an experimental feature. We are still not aware of the security implications of exposing some Electron renderer APIs to the preload script
If the content you're loading in the BrowserView never needs to communicate back to the application, then you don't need a preload script at all and can just sandbox the BrowserView.
After looking at the security and best-practices page, I will also append the following steps:
deny session permission requests from remote content (webcam, microphone, location, etc.)
catch webview elements in creation and strip default privileges
disable the creation of new windows
disable the remote module
Sure, those sound reasonable. Note that if your embedded browser needs to be able to open new windows (via window.open or <a target="_blank" />) then you'd have to allow popups.
That is a fair amount of steps to undergo in securing external content.
Sure, but is your main concern with the security of the app, or with how much work it takes to make it secure? Browser developers need to consider similar things to ensure webpages can't get access to the OS. It's just part of the game.
Again, this list merely minimizes the risk, it does not remove it. If your goal is to display a website, a browser will be a more secure option.
This is just saying that if all you're trying to do is display a website, then just use a browser since that's what they're there for.
If you need to do other things, well then you can't use a browser, so you'll have to make your own app, making sure it's reasonably secure.
I think that if you follow what's recommended in the Security document and keep up to date with new Electron releases, then you're doing the best you can do.
As for whether that's good enough, I can't say. It depends on what you're developing and what you're trying to protect against.
However, my thoughts can't substitute the more expert opinions of those on the Electron team. This question could certainly use some guidance from them.
Making a EXISTING CMS site compatible for mobile site NOT REDIRECT
Hi All.
I am currently creating a mobile version of an expression engine site that we use.
I am having problems with this, because typically I can just use media quires, or use redirect scripts.
However, the layout of the mobile site will be completely different from the desktop, so I can't just fiddle with a media quires for the CSS (as site just looks to different).
I was thinking of using a javascript to wipe the code or markup (php) if the device is mobile BUT it would mean perhaps loading two versions of code anytime a page loads up (not good for mobile). Eg one code for desktop and another for mobile.
I can't change the file names eg (mobile_index) because it is a CMS and the links wont link up correctly. I have tried this a few times , and also editing the .HTACCESS file, but it simply didnt work.
So if anyone knows how do I change the code of a page if the device mobile, but cant change file name, directory or any of that :-)
Cheers
Daragh
Why no redirect? If I was in your position, which I was a few months ago, I would handle this totally different:
Install Multiple Site Manager by ExpressionEngine: http://expressionengine.com/user_guide/cp/sites/index.html
Add another site -- mobile
Give it a proper domainname like m.domain.com
Give it its own template group
... and redirect with http://github.com/sebarmeli/JS-Redirection-Mobile-Site/
Now you can manage both installations from the same CMS and both installations can access existing channels, modules, extensions and members. This will keep your code fast and clean.
Adding a bunch of conditionals will only slow down installation.
Actually you could mess with media queries - it's the most flexible. JS is really overkill for something like this. At larger sizes, UL>LI menus could appear, and at smaller sizes they could be hidden (display:none) and swapped to select lists; divs can be replaced, elements dropped or resized. I also combine them with different snippets or embeds so you can tailor the content out as well.
You might try something like MX Mobile Device Detect. It gives you some variables that can detect if the user is on a mobile device that you could use in conditionals in your templates.
We're building a mobile-friendly site to work in tandem with our client's MOSS 2007 internet site. We need to be able to redirect users who hit the home page and are using a mobile device.
Our original intention was to add a custom control to the home page page layout that would detect the current user's device and redirect to the mobile site accordingly. We quickly realised that this would not work as we are using the Output Caching functionality provided by SharePoint/Asp.Net. This means that the detection code will only run for the first visitor to the home page until the cache expires.
Our next idea was to build a custom HTTP Module and process the detection there. However, we are finding that the Output Caching is not allowing that either. If the cache is set while a mobile device is visiting all browsers are subsequently redirected to the mobile site (until the cache expires).
If we turn off output caching it works just fine - but we cannot turn output caching off, especically for the home page. We did investigate Substitution (Donut) Caching but this is not working due to the fact we are filtering the Asp.Net response within another HTTP Module that tidies up the rendered HTML for XHTML compatiblity reasons. I've also experimented with the output cache profile by setting it to vary-by-header property to "User-Agent" but I am getting mixed results and am also concerned at the memory implications of caching multipel versions of pages (we already have memory issues now and then).
It's possible we could run the redirection code in JavaScript but then we risk not detecting a lot of devices that don't have JavaScript enabled. This is a government website so the usage of JavaScript has to abide by accessibility guidelines.
Does anyone have any other ideas as to how we can solve this issue. Has anyone done this before? Perhaps in a different way?
Hope you can help, thanks.
p.s. I have also asked this question on SharePoint.SE but wanted to get as many eyes on this as possible.
I would suggest you to try ISAPI filters
I've actually solved this one I think. I've pretty much followed this article here - http://msdn.microsoft.com/en-us/library/ms550239.aspx. We have updated the code in that article to build a cache key based on whether the current page is the home page, whether the current user is using a mobile device and whether or not a cookie exists forcing the user to the full site. I will probably write this up as a blog post. When I do I will update this answer providing a link.
A couple sites of mine recently got "hacked". Someone was able to add a line of JavaScript to the bottom of every page on the site.
The server is a Windows Server 2003, and has Cold Fusion 8 and MySQL 5.x installed and running.
Looking into the code on each page shows that none of the pages were modified. The JavaScript is not in the code files themselves. This leads me to believe it is an IIS problem, but I am unsure and cannot find anything that would be able to do this within IIS.
The JavaScript being added redirects a user to another page only when they come from Google, or at least it appears to work this way.
Any help on how someone was able to accomplish this as well as removing it would be greatly appreciated.
Another way to word the question thanks to #Jeffrey Hantin
How do you systematically modify output from IIS without modifying individual pages?
EDIT: A bit more testing has shown that only the .cfm pages add the extra javascript. Added a new .cfm and the js was there but a .html did not have it.
Edit2: Turns out to have been a coldfusion problem after all. Somehow the pages OnRequestEnd.cfm were created on the sites and added that js.
Looks like someone exploited some latest Adobe CF vulnerabilities.
Please see these blog posts for details and try to search symptoms on your server:
Image upload
FCKEditor bug + this post
Hope this helps.
Turns out to have been a coldfusion problem after all. The page OnRequestEnd.cfm were created on the sites and added that js.
If you only want to use IIS to modify output, the ISAPI filter is probably the best answer. If you would like to use Coldfusion, you could utilize the application.cfc to modify output during certain parts of the request cycle or wrap all of your pages in a Custom Tag to consolidate the like portions of your page templates.
I have used both. In cases where my page headers and footers are all the same, the custom tag is fast and easy to use. To make changes to all the pages, you edit one custom tag file. In cases where I have a more complicated web application I'll use the application.cfc to store and insert common components where they are needed.
They might have guessed your password. You should change it immediately.
It's possible that an ISAPI filter is used to do this. I once used one myself to perform compression before IIS supported it natively.
In your specific situation, you may want to check for ISAPI filters you don't want installed. Of course, if your server has been compromised, you will likely be better off rebuilding from a known good image rather than trying to fix it in situ.
We have a CMS system whose web interface gets served over HTTPS. This works beautifully for Firefox, but when we load it in IE6 or IE7, it complains that "This page contains both secure and nonsecure items."
I've loaded the page in Firefox and checked with Firebug, and every connection seems to be going through HTTPS, as should be the case.
Is there any way to tell what is causing IE to throw this apparently spurious error?
Firefox has a number of bugs in mixed content detection. Generally you should try using Fiddler to spot insecure resources.
If you install a tool I wrote (www.bayden.com/dl/scriptfreesetup.exe) you will get a different mixed content prompt which shows the exact URL of the first insecure resource on the page. That tool is basically a prototype and you should uninstall it when you're done with it.
Use Fiddler to watch the traffic between the server and IE.
Be sure to go to Tools > Fiddler Options... > HTTPS > and check 'Decrypt HTTPS traffic'
Any non-HTTPS traffic generated between any server and IE should be easy to spot in the Web Sessions list.
I used Eric's tool (thanks Eric you saved me hours...) and it turns out that IE6 treats a background image specified with a relative path as nonsecure content. Even though it actually requests it over https. So if you're stumped - converting your relative paths to absolute ones might really help...
Are one or more resources (CSS url-image ref overlooked easily) pointing to a subdomain that's not covered by the certificate (https://www.example.com vs https://static.example.com)?
If you can't see anything that isn't using SSL, then this is usually down to a broken SSL certificate somewhere. I don't know of anything off-hand that will tell you what exactly what the problem is, but you can get a list of everything that's loaded easily enough.
The media tab on Firefox's 'page info' dialog (right click on the page) will do it, it might also be worth having a go with Fiddler (which is an excellent, and extremely useful piece of software).