Archive

Posts Tagged ‘http’

Security through obscurity – hiding your server version information

August 31st, 2014 No comments

I’ve recently spent a lot of time reviewing the OWASP documentation, and (like many corporations) realized that I’d neglected to keep up with this configuration item.

By sharing the exact version of each piece of server software you are using, “hackers” are able to quickly identify unpatched systems and their known vulnerabilities.

To make their work harder, there are a few simple steps that the server admin can take to remove this information from the HTTP Headers and error pages.

Apache HTTPd:

  1. sudo vi /etc/apache2/conf-enabled/security.conf
  2. Add:

    ServerTokens ProductOnly
    ServerSignature Off
  3. If using virtual hosts, add the following to each one:
    ServerSignature Off
  4. sudo service apache2 restart

Apache Tomcat:

  1. vi /opt/tomcat7/conf/server.xml
  2. Find the <Connector > entry and add:
    server="Apache"
  3. cd /opt/tomcat7/lib
  4. mkdir -p org/apache/catalina/util
  5. vi /opt/tomcat7/lib/org/apache/catalina/util/ServerInfo.properties
    server.info=Apache Tomcat
  6. sudo service tomcat7 restart

PHP “X-Powered-By: PHP/5.x.x-1ubuntuX.X”

  1. sudo vi /etc/php5/apache2/php.ini
    expose_php = Off
  2. sudo service apache2 restart

REFERENCES:

Preventing Blackberry browser from messing up your UI

August 10th, 2014 No comments

I’ve previously given steps to prevent phone numbers (and other elements) from being automatically reformatted by Skype Toolbar and IOS Safari, there is still a small segment of the user population that uses Blackberry devices that can similarly benefit from a little code.

The following stops auto detection and formatting of phone and email addresses on devices with the BlackBerry Browser.

HTML:

<meta http-equiv="x-rim-auto-match" content="none" />

WML:

<meta name="x-rim-auto-match" http-equiv="x-rim-auto-match" forua="true" content="none" />

REFERENCES:

Comcast Business Class gateway forwarding port 22 for SSH

March 13th, 2014 No comments

For as long as I’ve had Comcast, and other providers for that matter, I’ve been able to configure my internet gateway/router to allow port 22 (SSH) access to an internal machine. It came as a surprise to me earlier this week that I was blocked when I tried to use their web admin console to change the internal forwarding to a newer machine. As usual, Technical Support was less that helpful and said that it was not possible to do so, and never should have been as Comcast uses that port to administer the gateway. To make matters more disturbing, I was told that I could not have similar SSH access to the gateway, and that replacing their hardware, while permitted, would prevent my use of a static IP.

Back to the solution, as I know that I had only setup this forwarding about a year ago, and it was working only minutes before I tried to change it, I knew that the configuration was possible if I could figure out how it was being blocked. The message in the web console was a javascript alert(); and gave me a starting point. I opened up Firefox and used Firebug to look for the message. Here are a few interesting findings from:

http://HOSTNAME/user/feat-firewall-port-forward-edit.asp

var RemoteManagementPortsCgiBase = “8080,8080,1\|8181,8181,1\|2323,2323,1\|22,22,1\|”;

msg += “Public Port Range conflict with Remote Management Ports.\n”;

if (msg.length > 1)
{
alert(msg);
return false;
}
return true;
}

If you even a little bit of javascript (or simple computer programming for that matter), the solution is clear…. if the ‘msg’ value is empty you will not see the alert or be prevented from making the change you desire.

Lesson to be learned by the Comcast developers (or most likely = subcontractors), always validate submitted form data in your application code, NEVER rely upon javascript alone to verify user entered data!

I also find it interesting that they are also preventing 8080, 8081 and 2323… perhaps that’s their other back doors in these gateways for their access. The same approach should work for those ports if you need it!

Name based virtual hosting with Apache2 on Ubuntu

February 1st, 2014 No comments

I often find it necessary to setup a temporary server for testing web applications. The easiest way to support this is often to create an integration (beta) test server that can be configured to support multiple hosts.

Initial Installation:

sudo apt-get install apache2
sudo a2enmod proxy
sudo a2enmod proxy_http
sudo a2enmod rewrite
sudo chmod 755 /var/www

To add a new site:

cd /etc/apache2/sites-available
sudo cp 000-default.conf yourdomain.com.conf
sudo vi yourdomain.com.conf
(change values as appropriate)
sudo chown -R YOURUSER:YOURGROUP yourdomain.com.conf
sudo mkdir -p /var/www/yourdomain.com
sudo chmod 755 /var/www
sudo vi /var/www/yourdomain.com/index.html
(add some fluff)
sudo chown -R YOURUSER:YOURGROUP /var/www/yourdomain.com
sudo a2ensite yourdomain.com
sudo service apache2 reload
sudo service apache2 restart

NOTE: replace YOURUSER and YOURGROUP with appropriate values for your server.

Content-Security-Policy HTTP Header

July 19th, 2013 No comments

There’s yet another new means to ‘help’ client User-Agents with preventing XSS on your websites.

In it’s simplest form you can simply use the following HTTP Header(s), the second one is for earlier versions of Webkit (Chrome/Safari):

Content-Security-Policy: default-src 'self'
Webkit-CSP: default-src 'self'

You can also add to the above to permit assets to load from other sources.
For example, if you were to permit javascript files from example.com you could include:

Content-Security-Policy: default-src 'self'; script-src http://example.com

Additionally, while failures are noted in the client’s browser console (that most users are not aware of), you can have them sent back to your server by adding a ‘report-uri’ attribute with an appropriate handler:

Content-Security-Policy: default-src 'self'; report-uri http://example.com/csp-report.php

REFERENCES:

Device Fingerprinting

July 16th, 2013 No comments

Often it can be beneficial to ‘more’ uniquely identify your users. For applications this is trivial, but in a web browser this can be accomplished via only a few attributes.

  • HTTP – User-Agent, IP Address, Content types and languages accepted.
  • HTTPS/SSL – the keys and encryption methods available to a specific user may vary for each client configuration.
  • HTML5 – local storage and capabilities supported.
  • Geolocation – this is included in HTML5, but also supported in many clients without full HTML5 support, or via browser extensions.
  • JavaScript – Installed version – and many DOM attributes/capabilities such as timezone, installed plugins, screen sizes and fonts from the browser can be detected.
  • Java (Applet) – Installed version – this can often be used to get additional information regarding the client system directly from the VM or Operating System itself. (* Persistent Cookies possible)
  • Flash – Installed version – this can often be used to get additional information regarding the client system directly from the Operating System itself. (* Persistent Cookies possible)
  • Silverlight (for Microsoft Windows) – – Installed version and additional information from Operating System?
  • GoogleGEARS (deprecated) – Installed version and additional information from Operating System such as Geolocation

REFERENCES:

Google ChromeFrame

July 8th, 2013 No comments

There was some debate back when this was first revealed in 2009, but the use of ChromeFrame is still relevant for some organizations that are stuck on older browsers for legacy applications.


<meta http-equiv="X-UA-Compatible" content="chrome=1" /><!-- this is for all versions of IE -->
<meta http-equiv="X-UA-Compatible" content="chrome=IE6" /><!-- this is for IE6 and lower -->
<meta http-equiv="X-UA-Compatible" content="chrome=IE7" /><!-- this is for IE7 and lower -->
<meta http-equiv="X-UA-Compatible" content="chrome=IE8" /><!-- this is for IE8 and lower -->
<meta http-equiv="X-UA-Compatible" content="chrome=IE9" /><!-- this is for IE9 and lower -->
<meta http-equiv="X-UA-Compatible" content="IE=Edge,chrome=IE6" /><!-- this is for IE9 and lower, passes Edge to others -->

NOTES:

  1. Installation can be done without Administrative rights on the Windows OS.
  2. Installation will append the ‘chromeframe’ version to the ‘User-Agent’ HTTP header sent by the browser to allow it to be parsed.

REFERENCES:

Morfeus scanner

December 2nd, 2012 No comments

I was scanning my server log files the other day and found that this old “bot” is still making the rounds. It help’s to shut the door on this with some configuration. It’s specifically looking for PHP vulnerabilities and is easily identified by the expletive in it’s User-Agent HTTP request headers.

REFERENCES:

Categories: WebStandards, Work Tags: , , , ,

X-XSS-Protection HTTP Header

December 1st, 2012 No comments
Categories: WebStandards, Work Tags: , , , , , ,

Cross-Origin Resource Sharing (CORS) Header

November 30th, 2012 No comments

Crossdomain access can be enabled in JavaScript with a mechanism similar to that in Flash. Instead of hosting a crossdomain.xml file though, crossdomain access is enabled per file, through an additional HTTP response header:

Access-Control-Allow-Origin: *

CORS is a more modern equivalent to JSONP for cross-domain XmlHttpRequests(AJAX) with options to limit domains, subdomains and ports.

Initial browser support:

  • Firefox 3.5
  • Chrome 4
  • Safari 3.2
  • MSIE 8

REFERENCES: