Web Application Security

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.


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.


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:

  1. 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.
  2. Making sure that you use coding best practice santising your web applications and all other components of your IT infrastructure.
  3. 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’.


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..


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.

Black Box Testing Strategy

What is a Black Box Testing Strategy?

Black Box Testing is not a type of testing; it instead is a testing strategy, which does not need any knowledge of internal design or code etc. As the name “black box” suggests, no knowledge of internal logic or code structure is required. The types of testing under this strategy are totally based/focused on the testing for requirements and functionality of the work product/software application. Black box testing is sometimes also called as “Opaque Testing”, “Functional/Behavioral Testing” and “Closed Box Testing”.

The base of the Black box testing strategy lies in the selection of appropriate data as per functionality and testing it against the functional specifications in order to check for normal and abnormal behavior of the system. Now a days, it is becoming common to route the Testing work to a third party as the developer of the system knows too much of the internal logic and coding of the system, which makes it unfit to test the application by the developer.

In order to implement Black Box Testing Strategy, the tester is needed to be thorough with the requirement specifications of the system and as a user, should know, how the system should behave in response to the particular action.

Various testing types that fall under the Black Box Testing strategy are: functional testing, stress testing, recovery testing, volume testing, User Acceptance Testing (also known as UAT), system testing, Sanity or Smoke testing, load testing, Usability testing, Exploratory testing, ad-hoc testing, alpha testing, beta testing etc.

These testing types are again divided in two groups: a) Testing in which user plays a role of tester and b) User is not required.

Testing method where user is not required:

Functional Testing:
In this type of testing, the software is tested for the functional requirements. The tests are written in order to check if the application behaves as expected.

Stress Testing:
The application is tested against heavy load such as complex numerical values, large number of inputs, large number of queries etc. which checks for the stress/load the applications can withstand.

Load Testing:
The application is tested against heavy loads or inputs such as testing of web sites in order to find out at what point the web-site/application fails or at what point its performance degrades.

Ad-hoc Testing:
This type of testing is done without any formal Test Plan or Test Case creation. Ad-hoc testing helps in deciding the scope and duration of the various other testing and it also helps testers in learning the application prior starting with any other testing.

Exploratory Testing:
This testing is similar to the ad-hoc testing and is done in order to learn/explore the application.

Usability Testing:
This testing is also called as ‘Testing for User-Friendliness’. This testing is done if User Interface of the application stands an important consideration and needs to be specific for the specific type of user.

Smoke Testing:
This type of testing is also called sanity testing and is done in order to check if the application is ready for further major testing and is working properly without failing up to least expected level.

Recovery Testing:
Recovery testing is basically done in order to check how fast and better the application can recover against any type of crash or hardware failure etc. Type or extent of recovery is specified in the requirement specifications.

Volume Testing:
Volume testing is done against the efficiency of the application. Huge amount of data is processed through the application (which is being tested) in order to check the extreme limitations of the system.

Testing where user plays a role/user is required:

User Acceptance Testing:
In this type of testing, the software is handed over to the user in order to find out if the software meets the user expectations and works as it is expected to.

Alpha Testing:
In this type of testing, the users are invited at the development center where they use the application and the developers note every particular input or action carried out by the user. Any type of abnormal behavior of the system is noted and rectified by the developers.

Beta Testing:
In this type of testing, the software is distributed as a beta version to the users and users test the application at their sites. As the users explore the software, in case if any exception/defect occurs that is reported to the developers.

Black Box Testing

beSTORM performs a comprehensive analysis, exposing security holes in your products during development and after release.

beSTORM represents a new approach to security auditing. This new approach is sometimes called “fuzzing”, “fuzz testing” or “fuzzer” and can be used for securing in-house developed applications and devices, as well as applications and devices of external vendors.

Most of the security holes found today in products and applications, can be discovered automatically. By using an automated attack tool that tries virtually all different attack combinations, with the ability to detect certain application anomalies and indicate a successful attack, those security holes can be found almost without user intervention.

How it works

  • Innovative beSTORM performs an exhaustive analysis to uncover new and unknown vulnerabilities in software products. This is different than older generation tools that use attack signatures or attempt to locate known vulnerabilities in products. beSTORM does not need the source code to analyze and uncover vulnerabilities.
  • Broad range Many of the common Internet protocols can be tested by beSTORM – even complex protocols such as SIP (used in Voice over IP products) are supported.
  • Attack Prioritization Special attack prioritizing algorithms allow beSTORM to start with the attacks most likely to succeed, depending on the specific protocol that is audited. This saves considerable time during the audit process and highlights the most important problems, first.
  • Report accuracy beSTORM checks the application externally by triggering actual attacks. Vulnerabilities are reported only if an actual attack has been successful, for example if a buffer overflow has been triggered. Simply put, beSTORM emulates an attacker. If the attacker cannot carry out the attack, beSTORM will not report it, effectively reducing the number of false positives.
  • Protocol compliance beSTORM is able to convert the protocol standard text to automated set of tests by converting the BNF description used in technical RFC documents to attack language. This ensures that the entire functionality of the system is checked, and enables to quickly find bugs that otherwise surface only months or years after the product is released to the market.
  • Comprehensive analysis beSTORM detects vulnerabilities by attaching to the audited process and detecting even the slightest anomalies. By doing so, beSTORM can find attacks as subtle as ‘off-by-one’ attacks, as well as buffer overflow attacks that do not crash the application.
  • Scaling beSTORM is extremely scalable, with the ability to use multiple processors or multiple machines to parallelize the audit and substantially reduce the testing duration.
  • Extensibility beSTORM tests the protocol rather than the product, and therefore can be used to test extremely complicated products with a large code base.
  • Flexibility beSTORM’s protocol analysis can be easily extended to support your proprietary protocol.
  • Language independent beSTORM tests the binary application, and is therefore completely indifferent to the programming language or system libraries used. beSTORM will report the exact interaction that triggers the vulnerability, and the programmers can now debug the application with whatever development environment they wish to see what causes the fault.

Automated Binary Analysis

beSTORM includes an automated engine that can parse through binary data, decode ASN.1 structures as well as length value pairs:

Automated Textual Analysis

beSTORM includes an automated engine that can parse through textual data, recognize multiple forms of data encoding, as well as decode XML structures:

Custom Protocols

For those protocols that cannot be automatically analyzed beSTORM includes a graphical interface that can be used to easily support your proprietary protocols:

Advanced Debugging and Stack Tracing

beSTORM includes an advanced debugging and stack tracing engine that can not only discover potential coding issues, but also show what is the stack trace that brought you to the specific coding issue:


  • Integrates with the existing development strategy Search for security vulnerabilities during development or as part of your QA process.
  • Source code not necessary No need for source code – perfect for auditing 3rd party applications.
  • Reproducable Vulnerabilities are searched for in a methodical way which can be reproduced.
  • Powerful substitute beSTORM can be used to substitute existing tools used by security auditors and black-box testers.