How would you determine whether your website is being hacked or not? Read the way hacker steals the information and hacks your website. Moreover, how you can help preventing your website being hacked.
IS YOUR WEBSITE HACKABLE?
Some hackers, for example, will take advantage of web application vulnerabilities and may maliciously inject code within vulnerable web applications to trick users and redirect them towards phisphing sites. This technique is called Cross-Site Scripting and may be used even when the web servers and database engine contain no vulnerabilities themselves.
Is your data really safe?
Just because you think your data is safe does not mean your database of sensitive organization information has not already been cloned and is resident elsewhere ready to be sold to the highest bidder. To make matters worse, only recently, it has been discovered that hackers are not simply selling your data; they’re also selling the fact that you have vulnerabilities to others be they hackers, industrial spies or terrorists.
It all sounds apocalyptic, doesn’t it? Well, rather than being an angel of doom, I’ll let the stats speak for themselves.
web Hacking Incidents Database
The web hacking incident database (WHID) is a Web Application Security Consortium project dedicated to maintaining a list of web applications related security incidents.
The database is unique in tracking only media reported security incidents that can be associated with a web application security vulnerability. We also try to limit the database to targeted attacks only. Please refer to the FAQ for further information on what you will find and what you will not find in WHID.
WHID goal is to serve as a tool for raising awareness of the web application security problem and provide information for statistical analysis of web applications security incidents. WHID has been features in Week and slash dot
If you have additional information on those or other web hacking incidents, you are more than welcome to share this information with us.
Example
IndiaTimes.com Visitors Risk High Exposure To
The web site of a leading Indian newspaper is swamped with malware. A recent survey by WebSense cites by the Register found that of the sites hosing malware, 51% where legitimate sites that have been broken into. This is a major shift in the threat landscape, since keeping to web sites that you know is no longer a good protection strategy. Anecdotally undermining WebSense own web site classification technology as a security solution.
SQL injection vulnerabilities
Securing your website and web applications from SQL Injection involves a three-part process:
- Analysing the present state of security present by performing a thorough audit of your website and web applications for SQL Injection and other hacking vulnerabilities.
- Making sure that you use coding best practice santising your web applications and all other components of your IT infrastructure.
- Regularly performing a web security audit after each change and addition to your web components.
Furthermore, the principles you need to keep in mind when checking for SQL Injection and all other hacking techniques are the following: “Which parts of a website we thought are secure are open to hack attacks?” and “what data can we throw at an application to cause it to perform something it shouldn’t do?”.
Checking for SQL Injection vulnerabilities involves auditing your website and web applications. Manual vulnerability auditing is complex and very time-consuming. It also demands a high-level of expertise and the ability to keep track of considerable volumes of code and of all the latest tricks of the hacker’s ‘trade’.
The best way to check whether your web site and applications are vulnerable to SQL injection attacks is by using an automated and heuristic web vulnerability scanner.
An automated web vulnerability scanner crawls your entire website and should automatically check for vulnerabilities to SQL Injection attacks. It will indicate which URLs/scripts are vulnerable to SQL injection so that you can immediately fix the code. Besides SQL injection vulnerabilities a web application scanner will also check for Cross site scripting and other web vulnerabilities.
Apache Web Server Security
An increasing number of attacks on high-profile websites show that web security is still one of the most critical issues to be tackled by any business that has a web presence and conducts operations online.
If your web server and/or web applications are vulnerable to attacks, you can be giving a free access to hackers to access sensitive information stored in your backend database.
One of the elements of your network infrastructure that could be vulnerable to attacks is the web server program. A web server program or web server engine runs a service which listens for, and responds to, web requests made by users via their browser. The most widely used web server engines are Apache and Microsoft IIS. These web server programs could very well exhibit security flaws or vulnerabilities, which, for example, could allow a malicious remote user access to your operating system with privileges which are more wide-ranging than those normally provided to a web browser request.
Furthermore, Apache requires a server-side scripting engine (e.g., PHP, ASP, ASP.NET, JSP) if the website is dynamic or if, for example, certain pages require the user to submit personal information such as their name, email address and credit card details. Web security best practice requires regular auditing to check for scripting engine vulnerabilities, as well as, ensuring that users cannot input character combinations that could exploit these or other weaknesses to eventually gain access to sensitive data.
PHP Security
Whether your site is the web presence for a large multinational, a gallery showing your product range and inviting potential customers to come into the shop, or a personal site exhibiting your holiday photos, web security matters. After the hard work put in to make your site look good and respond to your users, the last thing you want is for a malicious hacker to come along, perform a PHP hack and break it somehow.
There are a number of problems in web security, and unfortunately not all of them have definite solutions, but here we’ll look at some of the problems that should be considered every time you set out to write a PHP script to avoid a PHP hack attack. These are the problems which, with well-designed code, can be eliminated entirely. Before looking in detail at the solutions, though, lets take a moment to define the problems themselves.
SQL Injection
In this attack, a user is able to execute SQL queries in your website’s database. This attack is usually performed by entering text into a form field which causes a subsequent SQL query, generated from the PHP form processing code, to execute part of the content of the form field as though it were SQL. The effects of this attack range from the harmless (simply using SELECT to pull another data set) to the devastating (DELETE, for instance). In more subtle attacks, data could be changed, or new data added.
Directory Traversal
This attack can occur anywhere user-supplied data (from a form field or uploaded filename, for example) is used in a filesystem operation. If a user specifies “../../../../../../etc/passwd” as form data, and your script appends that to a directory name to obtain user-specific files, this string could lead to the inclusion of the password file contents, instead of the intended file. More severe cases involve file operations such as moving and deleting, which allow an attacker to make arbitrary changes to your filesystem structure.
Authentication Issues
Authentication issues involve users gaining access to something they shouldn’t, but to which other users should. An example would be a user who was able to steal (or construct) a cookie allowing them to login to your site under an Administrator session, and therefore be able to change anything they liked.
Remote Scripts (XSS)
XSS, or Cross-Site Scripting (also sometimes referred to as CSS, but this can be confused with Cascading Style Sheets, something entirely different!) is the process of exploiting a security hole in one site to run arbitrary code on that site’s server. The code is usually included into a running PHP script from a remote location. This is a serious attack which could allow any code the attacker chooses to be run on the vulnerable server, with all of the permissions of the user hosting the script, including database and filesystem access.
Validating Input And Stripping Tags
When a user enters information into a form which is to be later processed on your site, they have the power to enter anything they want. Code which processes form input should be carefully written to ensure that the input is as requested; password fields have the required level of complexity, e-mail fields have at least some characters, an @ sign, some more characters, a period, and two or more characters at the end, zip or postal codes are of the required format, and so on.
Each of these may be verified using regular expressions, which scan the input for certain patterns. An example for e-mail address verification is the PHP code shown below. This evaluates to true if an e-mail address was entered in the field named ’email’.
preg_match(‘/^.+@.+\..{2,3}$/’,$_POST[’email’]);
This code just constructs a regular expression based on the format described above for an e-mail address. Note that this will return true for anything with an @ sign and a dot followed by 2 or 3 characters. That is the general format for an e-mail address, but it doesn’t mean that address necessarily exists; you’d have to send mail to it to be sure of that.
Authentication Hacking Attacks
HTTP can embed several different types of authentication protocols. These include:
- Basic – Cleartext username/password, Base-64 encode (trivially decoded)
- Digest – Like Basic, but passwords are scrambled
- Form-based – A custom form is used to input username/password (or other credentials) and is processed using custom logic on the backend.
- NTLM – Microsoft’s proprietary authentication protocol, implemented within HTTP request/response headers.
- Negotiate – A new protocol from Microsoft that allows any type of authentication specified above to be dynamically agreed upon by the client and server. Also adds Kerberos for clients using Microsoft’s IE v5+.
- Client-side Certificates – Although rarely used, SSL/TLS provides an option that checks the authenticity of a digital certificate present by the Web client, essentially making it an authentication token.
- Microsoft Passport – A single-sign-in (SSI) service run by Microsoft Corporation that allows web sites (called “Passport Partners”) to authenticate users based on their membership in the Passport service. The mechanism uses a key shared between Microsoft and the Partner site to create a cookie that uniquely identifies the user.
These authentication protocols operate right over HTTP (or SSL/TSL), with credentials embedded right in the request/response traffic.
This kind of attack is not a technological security hole in the Operating System or server software. It depends rather on how securely stored and complex the passwords are and on how easy it is for the attacker to reach the server (network security).
Fallout From the Fall of CAPTCHAs
CAPTCHA went from relatively obscure security measure perfected in 2000 by researchers at Carnegie Mellon University to deployment by most of the major Web e-mail sites and many other Web sites by 2007. Sites such as Yahoo Mail, Google’s Gmail and Microsoft’s Hotmail all used — and, for that matter, continue to use — CAPTCHA to make sure that only human beings, not bots, could get accounts or make postings.
Those days are long gone.
By January 2008, Yahoo Mail’s CAPTCHA had been cracked. Gmail was ripped open in April. Hotmail’s top got popped during the same month.
And then things got bad. ”
QA Testing and Developer Awareness
Traditionally, Quality Assurance (QA) teams have not been partners with information security personnel, but trends are showing a shift in thinking. Mercury Interactive, a major player in automated testing tools, recently announced partnerships with some leading application security testing companies that provide an integrated solution between Mercury’s testing products and the vendors’ application vulnerability detection tools.
Does this mean QA teams will become security experts? Quite the contrary. We can expect to see more integrated solutions to allow QA testers to continue automated testing, without necessarily needing to understand the underlying security technology. In fact, we will most likely see a shift towards some type of workflow in which the owners of security policies create the appropriate tests and the QA professionals execute and measure against those tests.
We should also expect to see QA teams move from functional testing into areas of compliance testing as well. For example, for compliance with various state and federal privacy laws, QA teams could determine which web pages do not reference a privacy policy or which pages leak sensitive information in the URL of a form submission.
Developers will also benefit from increasingly sophisticated web application vulnerability detection tools. Ideally, detection systems should be able to track defective/insecure lines of code where vulnerabilities might be found. Whenever possible, this would happen as part of a development tool operation such as a compilation of code. Some vendors have created development tools for enhancing code security, but to date, sales of these tools have been relatively poor. In addition, most of these code scanning tools are unable to provide complete application awareness and can only focus on a specific module of code. Thus, for more complex problems that might extend, for example, between a UI module and a database module, code scanners have traditionally not worked very well as stand-alone solutions. It is also foreseeable that we will see integration with bug tracking systems so that developers can simply follow their current defect tracking methodology and fix security vulnerabilities as simply as functional defects in their code.
Closing the Loop
Eventually, web application security detection tools will be able to provide border appliances, such as intrusion detection systems (IDS’s) and firewalls, information on how to stop an attack until a vulnerability can be resolved. Various standards have emerged, each aligned with a particular set of vendors.
Some of the more prominent standards include the Application Vulnerability Description Language (AVDL) and Web Application Security (WAS), which are both XML-based standards. The shifting marketplace factors heavily into which standard will dominate. For example, Sanctum was recently acquired by WatchFire. It remains to be seen what the new parent company will establish as a strategic direction and/or if it shifts Sanctum’s original strategy to support WAS (which was formed as a competitor response to SPI Dynamics’ involvement in AVDL). While the industry appears to be favoring WAS, it is still unclear which standard will dominate and influence commercial product development. It’s also not clear how these standards will help customers. Right now, the focus for companies is to find critical vulnerabilities that they can remediate and thus protect themselves from cyber attacks..
Conclusion
The current use of most web application security testing tools is still focused on the penetration tester/information security professional, with use being extended for QA and audit professionals. We are still a fair distance from holding a developer (i.e., software vendors) accountable for writing insecure code, but clearly the trend is moving in that direction. Security has always been a holistic solution, requiring all players and systems to work in concert to form a good defense.
