Jun
22
2010

Peek-a-boooooooo – Default web pages, and why you should care to change or eliminate them

Just dropped 200 bucks on your new webcam (link will be opened in new window) you can use to check up on your pets from across the world? Does it do everything you hoped it would?

News flash – depending upon how it’s configured, it could be doing even more; that same page you browse to in order to check up on Fido may be indexed by search engines such as Google.

Now, 9 times out of 10, the web server is configured to host the content under a non-intuitive URL; while this may deter somebody who is trying to guess the URL used by the software, it also provides those “in the know” with a “one-stop shop” for all of their nefarious needs. As an example, most Panasonic networked cameras have the string “ViewerFrame?Mode=” in the URL, and can easily be located by using the Google search string inurl:”ViewerFrame?Mode=”.  If you’re following along with the links, I’m guessing (without actually accessing this page which was likely intended to be private) the third page on the above Google search (it’s a *.edu) is exactly what a hacker would want to see — and exactly what you don’t want them to see**.

To avoid this, it may be possible (depending upon the software) to at least change the default URL used. If not, consult the support documentation – and if necessary, the vendor – to determine the best course of action by which you can better protect your privacy. Depending upon the software leveraged by the device, you may also be able to create a robots.txt file (file including all pages not to be indexed by the search engine) for the web server as well.  For more detail, see here.

By the way, it’s not just cameras, but printers and telecommunications equipment (read: WOW) as well. A surprisingly vast listing of known devices (and information on their default pages) can be found here.

** The posted information is for educational purposes only, I neither recommend nor condone using the web as a tool for spying on others.  Don’t do it.

Jun
20
2010

Cross Site Scripting (XSS) Attack

“What is Cross Site Scripting?”

Cross site scripting (also known as XSS) occurs when a web application gathers malicious data from a user. The data is usually gathered in the form of a hyperlink which contains malicious content within it. The user will most likely click on this link from another website, instant message, or simply just reading a web board or email message. Usually the attacker will encode the malicious portion of the link to the site in HEX (or other encoding methods) so the request is less suspicious looking to the user when clicked on. After the data is collected by the web application, it creates an output page for the user containing the malicious data that was originally sent to it, but in a manner to make it appear as valid content from the website. Many popular guestbook and forum programs allow users to submit posts with html and javascript embedded in them. If for example I was logged in as “john” and read a message by “joe” that contained malicious javascript in it, then it may be possible for “joe” to hijack my session just by reading his bulletin board post. 

“What are the threats of Cross Site Scripting?”

Often attackers will inject JavaScript, VBScript, ActiveX, HTML, or Flash into a vulnerable application to fool a user (Read below for further details) in order to gather data from them. Everything from account hijacking, changing of user settings, cookie theft/poisoning, or false advertising is possible. New malicious uses are being found every day for XSS attacks. The post below by Brett Moore brings up a good point with regard to “Denial Of Service”, and potential “auto-attacking” of hosts if a user simply reads a post on a message board. 

Jun
19
2010

.htaccess 101: how to password protect a directory

What’s the easiest way to make an .htaccess file in Unix/Linux so that a directory is password protected? Suppose that your home directory is /home/dmistry and all your webstuff is in /home/dmistry/www/ . Follow these steps:

  1. Make an .htpasswd file. The htpasswd command in Unix does this. You should put the password file outside of your web directory. So a command like “htpasswd -bc /home/dmistry/.htpasswd review donotenter” will create a new file using a username of review and a password of donotenter into the file /home/dmistry/.htpasswd . If you were to run the command “cat /home/dmistry/.htpasswd” you might see a line like “review:M1OdtjdGiDn1Y”.
  2. Make an .htaccess file. In this case, the file would be located at /home/dmistry/www/.htaccess and it would look something like:
    AuthUserFile /home/dmistry/.htpasswd
    AuthName EnterPassword
    AuthType Basic
    <Limit GET POST>
    require valid-user
    </Limit>