Lets Talk a little bit about Web Application Security Testing Methodologies.

     Following all the steps in this methodology will not guarantee that you discover all the vulnerabilities within a given application. However, it will provide you with a good level of assurance that you have probed all the necessary regions of the application’s attack surface and have found as many issues as possible given the resources available to you.

We can say:

1. Step is "Map the Application’s Content"
2.Step is "Analyze the Application"

3.Step is "Test Client-Side Controls"

4.Step is "Test the Authentication Mechanism"

5.Step is "Test the Session Management Mechanism"

6.Step is "Test Access Controls"

7.Step is "Test for Input-Based Vulnerabilities"

8.Step is "Test for Function-Specifi c Input Vulnerabilities"

9.Step is "Test for Logic Flaws"

10.Step is "Test for Shared Hosting Vulnerabilities"

11.Step is "Test for Application Server Vulnerabilities"

12.Step is "Miscellaneous Checks"

13.Step is "Follow Up Any Information Leakage"

--- I will try to explain each step with examples later :) ---



Start to Install Web Servers for your attack-victim lab

After installing OSs in your virtual environment; we can continue with installing web servers.

1.IIS for windows servers and clients (for Win7 or Wion server 2003/2008/2008R2). You can find helpful instruction and documents for IIS on iis.net site.,

2. Apache Tomcat, it is another web server.You will need it,because %56 of web servers running Apache Tomcat (IIS is %26 ).Here is the link.

3. Nginx (only %15 web servers running that). Here is the link for Nginx.

and others (I am not gona talk about others :) ).

See you later.

WAST on Hire !

     If you are a web app developer (Small,Medium,Enterprise level ) and  if you need smbdy to test yor applications (a WAST Webb Application Security Tester) for vulnaribilities,especially against SQL Injection, and XSS/CSRF, and others, you can contact me via email.Leave yor contact info and I will contact you as soon as I can. 



Lets Start with building an attacker-victim LAB   :)

For Building an Attacker-Victim Lab;  Part I

1.you will need a good pc or server (I have HP proliant server with 8gb memory and 1.5 tb with Raid)

2. Virtualization Miracle (vmware,hyper-v,zen, ....whatever)

3. And start creating with your virtual machines : xp, win server 2003/2008, linux (back track preferred,and other ubuntu ,etc) because we will install IIS and also Apache server as our victims.

You should at least 5 virtual machines 1.Backtrack attacker (or 1 xp pro/win 7 as attacker, or both preferred), 2. a win server 2003 and/or 2008, 3. another linux (ubuntu for apache server) ...etc.

4. Download SQL Express from here. (and also learn MySql / Oracle also)

5. Download:  Burp, WebInspect, paros proxy, IBM AppScan,  Hp Scrawlr, Netsparker, Acunetix  and other fire fox add-ons such web developer, Tamper Data, Fiddler, HttpWatch, IEWatch, and important thing download and review their documentations /tutorials. 

 





WEB Application Security Tester TOOLKIT

  I think, if you want to become a WAST (Web App Security Tester-Pen Tester) you have to have;

1.Knowledge (experience) of at least "1" web application development programming and/or script language , such as; Java,C#,VB,Perl,Php,Ruby,Phyton etc, and Javascript, and Markup Languages such as; HTML,DHTML,XML,XHTML,..etc.

2. Knowledge of Web Services (WSDL, SOAP,AWS,...)

3. Knowledge of Web basics such as; Web Servers, Web clients, releated ports, protocols (TCP/IP),

    HTTP,HTTPS,URL,URI,SSL,Web proxies,..etc.

4. Knowledge of different OSs (Windows,Linux)

5. Knowledge of Web servers types (IIS,Apache,Nginx,...)

6. Knowledge of SQL and Database and Data Store systems (MS SQL,MySql,Oracle, ..etc)

7. Knowledge of Authentication systems (Basic,NTLM,Kerberos,..etc)

8. Andddddd Tools;

Back Track (it is HOLLY TOOL of  WASTS)

Vmware (or another virtual system-Dont harm yourself and others)

Burp (it is Awesome I'll tell you how ),

HP WebInspect (It is also good)

Web Developer

Tamper Data

HP Scrawlr

SQLiX

Paros Proxy

IBM Rational AppScan

Firefox Extension/Add-Ons,...etc.

We will talk about all of those and other tools a little later.  :(

See you later .

Ponemon State of Web Application Security Report

Despite numbers showing that in 86% of all attacks a vulnerability in a Web application was exploited, a new study by the Ponemon institute found that only 18% of IT security budgets are allocated to protecting Web applications.

WordPress Security

 

With over 9.7 million active installations of WordPress and 32 of the Technorati Top 100 ... read more ...

Network and host security are provided with hefty budgets, claiming 43% of the IT security pie even though they are only responsible for a small percentage of attacks, 14% by some numbers.
Some other numbers from, “The State of Application Security,” study show that:

• 70% of those who responded don’t believe that their organization allocates enough resources to protecting Web applications
• 34% of vulnerabilities considered urgent are not fixed
• 55% believe that developers are too busy to work on security issues
• 38% believe that to fix a vulnerability in a Web application it would take more than 20 hours
• 43% stated that Web application security is not a corporate priority and developers do not care about this

Ironically, almost three-quarters of those who responded to the survey claim that web security is viewed as a strategic initiative in their organization.
A great deal of the study focused on the developer. Amazingly, most felt that the developer is not responsible for the security of their applications thus allowing the task to fall on the shoulders of those responsible for security in the organization.
Traditionally, IT security focuses on defending the network through host and workstation based methods. Tools like intrusion prevention systems and traditional firewalls are used to defend the network from specific attacks however these safeguards are virtually worthless at protecting attacks launched at the application layer. Knowing that traditional defenses can’t keep them out, attackers look towards holes found in most Web applications as a means of compromising data and resources.
When dissecting the numbers, it looks like fixing vulnerabilities in Web application code is just too much trouble. True, code reviews take a great deal of time to perform and cost a great deal of money. Throw into the mix that organizations may not always have access to the code because of proprietary applications or outsourcing and it is easy to see why so many vulnerabilities go unfixed.
However the difficulty involved does not excuse the organization from having to fix what is broken. Regulations like HIPAA and Sarbanes-Oxley were put in place to protect data in US based organizations. Worldwide compliance with the Payment Card Industry’s Data Security Standards (PCI DSS) is a must for any organization that processes credit card payments. Compliance with any of these regulations cannot be simply swept under the rug because it’s just too hard to do.
Astonishingly, 70% of organizations who have deployed a Web application firewall fix vulnerabilities within one week of discovering them. Used in tandem with secure coding techniques, Web application firewalls can provide logs and analysis of attack patterns to help developers locate vulnerabilities and fix them at a faster rate than if they were simply pouring through lines of code and using automated scanning tools because the Web application firewall produces data related to real attacks. Of course, all the while the WAF is protecting the organization’s data and resources from being compromised because it is stopping attackers at their most common point of entry, the Web application itself.

CWE/SANS Top 25

With the release of the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors came a push to hold software developers to be held liable for any insecure code they write.

Alan Paller, director of research for the SANS Institute commented that "wherever a commercial entity or government agency asks someone to write software for them, there is now a way they can begin to make the suppliers of that software accountable for [security] problems."
Put in place to protect the buyer from liability, these efforts are also guided at producing secure code from the very beginning since vendors won’t be able to charge for fixing vulnerabilities found in their software.

Compiling the list

The Most Dangerous Programming Errors is a list compiled yearly by the Common Weakness Enumeration, a community initiative sponsored by the US Department of Homeland Security and the MITRE corporation, and the SANS Institute. Drawing from an international pool of approximately 40 software security experts from businesses, governments, and universities, the Top 25 are created by building from the previous year’s list through a private discussion board. Once the threats discussed were evaluated by the research team and the list was narrowed down to 41 entries. These entries were then rated according to two metrics: prevalence and importance and the 25 with the highest ratings were selected to the list. The ratings for prevalence were:

• Widespread - the weakness was encountered more frequently than most others
• High - the weakness is often encountered
• Common - the weakness is periodically encountered
• Limited - rarely is the weakness encountered

When looking at the importance of a threat, the ratings were:

• Critical - when addressing the weakness, it should be done as quickly as possible taking resources away from other tasks if necessary
• High - the weakness should be addressed as quickly as possible but not as urgently as a critical weakness
• Medium - these weaknesses should be addressed only after all high and critical weaknesses have been fixed
• Low - fixing the weakness is not urgent or important

The Top 25

In addition to ranking the Top 25 weaknesses, the report broke them down in to three categories: Insecure Interaction Between Components, Risky Resource Management, and Porous Defenses. The following table displays the rank, score, weakness, and category it falls under.

Rank	Score	Weakness	Category
1	346	Failure to preserve web page structure (Cross-site scripting)	Insecure interaction between components
2	330	Improper sanitization of special elements used in a SQL command (SQL injection)	Insecure interaction between components
3	273	Buffer copy without checking the size of input (Classic buffer overflow)	Risky resource management
4	261	Cross-site request forgery	Insecure interaction between components
5	219	Improper access control (Authorization)	Porous defenses
6	202	Reliance on untrusted inputs in a security decision	Porous defenses
7	197	Improper limitation of a pathname to a restricted directory (Path traversal)	Risky resource management
8	194	Unrestricted upload of a file with dangerous type	Insecure interaction between components
9	188	Improper sanitization of special elements used in an OS command (OS command injection)	Insecure interaction between components
10	188	Missing encryption of sensitive data	Porous defenses
11	176	Use of hard-coded credentials	Porous defenses
12	158	Buffer access with incorrect length value	Risky resource management
13	157	Improper control of filename for include/require statement in PHP program (PHP file inclusion)	Risky resource management
14	156	Improper validation of array index	Risky resource management
15	155	Improper check for unusual or exceptional conditions	Risky resource management
16	154	Information exposure through an error message	Risky resource management
17	154	Integer overflow or wraparound	Insecure interaction between components
18	153	Incorrect calculation of buffer size	Risky resource management
19	147	Missing authentication for critical function	Porous defenses
20	146	Download of code without integrity check	Risky resource management
21	145	Incorrect permission assignment for critical resource	Porous defenses
22	145	Allocation of resources without limits or throttling	Risky resource management
23	142	URL redirection to untrusted site (Open redirect)	Insecure interaction between components
24	141	Use of a broken or risky cryptographic algorithm	Porous defenses
25	138	Race condition	Insecure interaction between components

Dealing with Weaknesses

If developers are expected to ensure that their code is void of any weakness listed in the Top 25, they need to a) know how to identify the weakness and b) know how to prevent it. The report further breaks down those making the list and provides a detailed description for each weakness. These descriptions are broken down for the developer, providing a Summary that provides the weakness prevalence rating, a rating for the remediation cost, the attack frequency, the consequences of the weakness being exploited, how easy it is to detect the weakness, and how aware attackers are that the weakness exists. Following the summary is a discussion that provides the developer with a quick description of how an attack is carried out against the weakness and a sequence of prevention techniques to help developers avoid making such mistakes in their code.

What about OWASP

In developing their Top 25 list, CWE/SANS included a comparison to the OWASP Top Ten making a clear statement of the importance of OWASP’s list while also recognizing distinct differences between the two. Most clearly defined is that the OWASP Top Ten deals strictly with vulnerabilities found in web applications where the Top 25 deals with weaknesses found in desktop and server applications as well. A further contrast is seen in how the list is compiled. OWASP giving more credence to the risk each vulnerability presents as opposed to the CWE/SANS Top 25 that included the prevalence of each weakness. This factor is what gives Cross-site scripting the edge in the Top 25 as it is ranked number 1 while OWASP has it ranked at number 2.

Working with the Top 25

Pushing to make the Top 25 a checklist for developers to use to avoid lawsuits seems like the panacea for all programming vulnerabilities to those who support adopting such standards. Opponents claim that it will result in costlier software. Neither addresses what happens in the event of a zero-day attack. With an estimated 78% of all vulnerabilities being found in web applications, the likelihood of falling victim to an unknown threat is high.
So what happens if XYZ software abides by the Top 25 but weeks after deploying a new application, they are hit by an unknown threat? Is XYZ liable? Or is the buyer? And what if the buyer fails to protect the application? If the code is attacked as a result of their failure to secure other resources, where does the blame lie?
In my opinion, this has already been answered and is put into practice daily. Merchants who want to accept credit cards must comply with PCI standards that require either a code review or the deployment of a web application filter. Taking either route insures compliance but the recommendation is to make use of both solutions. Code review, which would help address Top 25 weaknesses, helps the developer indentify weaknesses and address them before releasing the application to the marketplace. Building secure code from the beginning is always a best practice to be followed. Combining this with the protection a web application firewall provides a line of defense against unknown vulnerabilities to stave off potential zero-day threats.

Microsoft confirms critical IE bug, works on fix

The Anatomy of a SQL Injection Attack

SQL injections are one of the most dangerous attacks used against web applications.

Computerworld - Microsoft late Wednesday confirmed that all versions of Internet Explorer (IE) contain a critical vulnerability that attackers can exploit by persuading users to visit a rigged Web site.

Although the company said it would patch the problem, it is not planning to rush out an emergency update.
"The issue does not currently meet the criteria for an out-of-band release," said Carlene Chmaj, a spokeswoman for the Microsoft Security Response Center (MSRC), in an entry on the center's blog. "However, we are monitoring the threat landscape very closely and if the situation changes, we will post updates."
Chmaj also downplayed the threat posed by the bug. "Currently the impact of this vulnerability is limited and we are not aware of any affected customers or active attacks targeting customers," she said.
The vulnerability in IE6, IE7 and IE8 surfaced several weeks ago when French security firm Vupen disclosed a flaw in IE's HTML engine. Tuesday, researchers posted a video demonstration of an attack, and added a reliable exploit to the Metasploit penetration toolkit.
That exploit used a technique revealed earlier this year by McAfee researchers that defeats a pair of important Windows defensive technologies -- ASLR (address space layout randomization) and DEP (data execution prevention) -- designed to stymie most attacks.
The appearance of the Metasploit attack code may have been what prompted Microsoft to take action, as the company's more technical "Security Research & Defense" blog highlighted the Metasploit module.
In that blog, Microsoft security software engineer J. Serna also confirmed that IE's "mscorie.dll" file does not always automatically enable ASLR, a technology that randomly allocates executable memory to make it difficult for hackers to run their code.
Until a patch is ready, Microsoft urged users to use the Enhanced Mitigation Experience Toolkit (EMET) utility to bolster IE's defenses. The company provided instructions on how to configure EMET to block attacks in the accompanyingsecurity advisory.
EMET is a tool designed for advanced users, primarily enterprise IT pros, and manually enables ASLR and DEP for specific applications. It's often used to reinforce older programs.
Microsoft has recommended EMET before as a stop-gap defense. In September, it told users to configure it to block attacks then targeting users of Adobe Reader. But this is just the second time that Microsoft has suggested users roll out EMET to protect an up-to-date Microsoft program.
EMET 2.0 is a free download available from Microsoft's site.
Users running IE7 or IE8 on Windows Vista and Windows 7 are less likely to be affected by a successful attack, Microsoft claimed, because those browsers include a feature called "Protected Mode" that prompts users before letting them install, run or modify certain operating system components.
Other browsers, including Firefox, Chrome, Safari and Opera, are not affected by the flaw.
The next regularly scheduled Patch Tuesday is Jan. 11, but because Microsoft usually updates the browser every other month, and just did so last week, it's possible the vulnerability won't be addressed until February.
Microsoft's usual practice is to release an emergency fix only if attacks appear and then grow in strength. Microsoft has never revealed how it sets the point at which a rush patch is triggered.
The last time the company issued an out-of-band update was late September when it patched a bug in the ASP.Net Web application framework.

The Most Vulnerable Programming Languages

WhiteHat Security recently released the results of a rather interesting study. Normally, studies of Web application security involves which type of vulnerability is most common or most dangerous to a web site. This study, however, looked into which programming language is the most secure among the many used to create Web based applications.

Microsoft confirms critical IE bug, works on fix suggests using blocking tool, but does not plan to issue emergency patch ... read more ...

As any frequent visitor to the various Internet forums knows, these results are sure to spark a plethora of flame wars among developers and security experts who stand up to defend their language of choice while at the same time finding flaws in another’s preference. These debates are healthy in the fact that they do expose vulnerabilities in the various languages, however many of the facts are based on heresay and insinuations. By taking emotion out of the debate, this report is able to take an outside look at which language presents the most risk. To gauge the results more accurately, the report also ignored attack surface and looked at the number of vulnerabilities found in a Web application written in a particular language rather than how many vulnerable applications were found in a particular language across the sample.

The Numbers Game

The results were measured in many different ways, yet two separate categories garner the most interest. The first one we will look at determined the average number of serious vulnerabilities found in application’s lifetime determines by the specific language in which it was written. The following ranks them in order:

• Perl – 44.8 vulnerabilities found per web site
• Cold Fusion (CFM) – 34.3 vulnerabilities found per web site
• PHP – 26.6 vulnerabilities found per web site
• JSP – 25.8 vulnerabilities found per web site
• Struts (DO) – 19.9 vulnerabilities found per web site
• Microsoft ASP – 25 vulnerabilities found per web site
• Microsoft .NET ASPX – 18.7 vulnerabilities found per web site

Additionally, the length of time it took to fix a vulnerability found in a specific language is of interest. The report dissects these results by specific vulnerabilities but by looking at two of the most common, and most dangerous threats, SQL Injection and Cross-Site Scripting, you can see a rather frightening pattern. These are ranked in order from highest to lowest in the number of days a fix took to patch an XSS vulnerability:

• Microsoft .NET ASPX - 87 days for XSS, 52 days for SQL Injection
• Microsoft ASP – 84 days for XSS, 44 days for SQL Injection
• Struts (DO) - 76 days for XSS, 52 days for SQL Injection
• Cold Fusion (CFM) - 72 days for XSS, 79 days for SQL Injection
• JSP - 67 days for XSS, 56 days for SQL Injection
• Perl - 53 days for XSS, 45 days for SQL Injection
• PHP - 52 days for XSS, 51 days for SQL Injection

Unacceptable Results

With so many cyber criminals using automated tools to find and attack vulnerable web sites, these numbers are simply unacceptable. While fingers can be pointed at developers, management, executives, etc. the fact remains that tools need to be deployed to protect Web applications against these threats. Code reviews are great and they are the best way to find the source of a vulnerability so that it can be fixed for good, however the data shows that it cannot be the only route an organization takes to secure their web sites or they are as good as compromised. Without tools like Web Application Firewalls to stop attacks before the vulnerabilities can be fixed Web applications will continue to be sitting ducks.

WikiLeaks, the Mega-D botnet and online privacy led the way in cyber-security news this past week.

Top Jordan website back up after hacking

AMMAN — Jordan's most popular news website, Ammonnews, said it was shut down ... read more ...

The saga that is the WikiLeaks controversy dominated security news this past week as governments around the world dealt with the fallout from the breach and the site dealt with denial-of-service attacks.WikiLeaks’ posting of more than 250,000 diplomatic cables online for many highlighted insider security and forced a re-examination of security policies by the U.S. government. But it also drew attacks. Just hours before the site began posting the cables Nov. 28 it experienced a denial-of-service attack (DoS), reputedly at the hands of a hacker known as “The Jester.” Another attack followed that one day later.
According to The New York Times, among the cables was one quoting a Chinese person with “family connections to the elite” as saying the Chinese government directed the infamous Aurora attack on Google and other companies, something Chinese officials have denied in the past. Other cables discussed the conflicts between Google and China regarding censorship of the Internet.
As the controversy spiraled, Amazon decided to stop hosting WikiLeaks on its servers, a move the company contends was not made due to political pressure but instead because WikiLeaks had violated Amazon’s terms of service. In addition, PayPal cut WikiLeaks online donation account during the week.
Outside the WikiLeaks controversy, the U.S. government also made the news through a new report by the Federal Trade Commission on online privacy that proposed a "Do Not Track" mechanism to limit the tracking of online consumers by advertisers and companies.
“For example, consumers are largely unaware of their ability to limit or block online tracking through their browsers, in part because these options may be difficult to find; further, those consumers who know about these options may be confused by the lack of clarity and uniformity among the browsers in how choices are presented and implemented,” the report states.
“The most practical method of providing uniform choice for online behavioral advertising would likely involve placing a setting similar to a persistent cookie on a consumer’s browser and conveying that setting to sites that the browser visits, to signal whether the consumer wants to be tracked or receive targeted advertisements,” the report continues.
Researchers also told eWEEK the situation could be addressed by requiring browsers to append a string to HTTP headers. The header approach would be a "binary flag," where the browser could turn it on for every HTTP connection, just third party sites or sites defined by the user, said Harlan Yu of the Center for Information Technology Policy at Princeton University.
Protecting users drove a partnership between Google and Adobe Systems to bring sandboxing technology to a version of Flash Player bundled with Google Chrome 9.0.587.0, currently in Google's dev channel.
"Over the next few months, we will be testing and receiving feedback on this project," Peleus Uhley, senior security strategist for the Adobe Secure Software Engineering Team, wrote in a blog post. "Since this is a distinctly different sandboxing code base from Internet Explorer, we are essentially starting from scratch. Therefore, we still have a few bugs that we are working through. We hope that we can use this experience as a platform for discussing sandbox approaches with the other browser vendors."
But attackers were busy as well, targeting Facebook users in a resurgence of an old scam involving a bogus application promising to track who views user profiles. News also trickled out that the FBI had identified a man believed to be at the center of the Mega-D botnet, which once accounted for roughly a third of the world’s spam. The man, 23-year-old Oleg Nikolaenko, is accused of receiving more than $464,000 during a roughly six-month period in 2007 to spam out e-mails for a crew of criminals specializing in the sale of fake goods. Nikolaenko has pleaded not guilty to the charges.
“It’s encouraging to see law enforcement agencies going after these bot-herding criminals,” blogged Phil Hay, senior threat analyst with M86 Security. “Identifying and incapacitating the individuals behind the malware is one of the best ways to keep these giant spam-spewing systems in check.”

IIS Server Security

For years, Microsoft has had to contend with the impression that their products were not as secure as their counterparts. This was especially true when it came to Internet Information Services (IIS), the Microsoft web server. Much of the issues associated with ISS were related to the fact that many of the services were enabled by default.

 

Database Security Best Practices

Today, many tools make it easy for anyone to quickly set up a data-driven website, ... read more ...

Right out of the box, IIS could run as a fully functional web server without much need to configure various services. Unfortunately, attackers knew this and were able to compromise servers, and web sites, that relied on IIS because many of the administrators who installed the software were not aware of what steps they needed to take to secure this application.
Much has changed over the years. In response to an increase in web-based application attacks, Microsoft made attempts to increase security in all of their products, including IIS. In version 6, they rolled out what was referred to as a lockdown by default approach where many features and services were left out, or disabled, in the default installation. They were still available, however the administrator had to enable or install them giving them full knowledge that they were running. In version 7, this approach changed again to take on a minimum install approach where only the bare minimum components are installed giving attackers a much smaller surface to work from.

Risks Associated with IIS

Despite the strides taken to protect IIS 7 from attacks, there are still risks that a web administrator needs to be aware of if they are running this application as their web server - this is what makes using a WAF (Web application firewall) so appealing. Unfortunately, some of the things that make Microsoft’s IIS so appealing are also some of the issues that anyone using it needs to be aware of.

It is a Microsoft product

It is not insecure because it is a Microsoft product, but the fact that Microsoft still makes things easier for administrators still makes it a target. IIS can be installed and run on Server 2008 Core, which uses a command line interface rather than Windows. In this environment, the server is much more secure. However, when Windows is used the temptation to make use of Internet Explorer to connect to the web is far too great and happens far too often. When servers are allowed to access the web, they are put at risk. Windows makes it too easy for a lazy admin to simply fire up IE to find something from their server rather than a workstation.

It is too easy to install software

One of the biggest threats to security is a web application. Odds are that most servers using IIS are using Windows. In a Windows environment, it is far too easy to install web applications like WordPress, Joomla!, or ZenCart. Although this is a huge selling point, it also poses a risk because if the web administrator does not have background knowledge related to the vulnerabilities that are present in these, or any other web application, then they may unknowingly be installing insecure software onto their server.
Of course, this can be true of applications installed via a command line interface or GNU/Linux shell as well, however odds are that if a person is adept at using these tools, they are more aware of basic security risks as well.

Malware

Unfortunately for Microsoft, many web admins still remember what the Code Red and Nimda worms did to web servers using IIS. Defacing web sites, hitting them with Denial of Service attacks, and exploiting path traversal vulnerabilities.
Due to Microsoft’s market share, it will always be a preferred target for malware attacks. Even as engineers work to patch known vulnerabilities, the thousands of pieces of malware being released into the wild every day that pose significant threats to any server running Microsoft.

Protecting IIS

Like any server, certain steps need to be taken to harden the operating system against attacks. While malware prevention, Intrusion Detection/Prevention Systems, network firewalls, and all of the other tools and techniques help prevent some attacks, they don’t adequately prevent attacks launched against any third-party applications that have been installed on the server.
dotDefender protects IIS web servers against a variety of vulnerabilities to include:

• Path Traversal
• Known worms
• Remote Command Execution
• Probes
• Denial of Service attacks
• Compromised servers

By acting as a Security-as-a-Service solution, dotDefender is able to provide protection to web servers whether the admin has an extensive background in security or just a minimal amount of knowledge on the subject.
With dotDefender web application firewall you can avoid many different threats to web applications because dotDefender inspects your HTTP traffic and checks their packets against rules such as to allow or deny protocols, ports, or IP addresses to stop web applications from being exploited.
Architected as plug & play software, dotDefender provides optimal out-of-the-box protection against DoS threats, Cross-Site Scripting, SQL Injection attacks, path traversal and many other web attack techniques.
The reasons dotDefender offers such a comprehensive solution to your web application security needs are:

• Strong security against known and emerging hacking attacks
• Best-of-breed predefined security rules for instant protection
• Interface and API for managing multiple servers with ease
• Requires no additional hardware, and easily scales with your business

The Need to Avoid Attacks

Whether your web server is running IIS or Apache makes little difference. With hundreds of millions of dollars being stolen each year by cyber criminals vulnerabilities will continue to be a problem as known ones are exploited and new ones emerge.
In addition to money and data stolen as a result of compromised servers and web sites, businesses have to contend with a damaged reputation after an attack. When a breach of security occurs, customers and visitors second guess visiting that site if they know that they are not safe. Once the search engines find malware or spam on a web site, it can be flagged as malicious and removed from the search engine results page causing a loss in legitimate traffic.

Credit Card Security

Despite several attempts to establish different e-payment solutions, credit cards still remain the currency of choice when it comes to shopping on the Web. Some estimates expect that by the year 2014 online sales will be in the range of over $250 million with no signs of slowing down.

 

With over 9.7 million active installations of WordPress and 32 of the Technorati Top 100 ... read more ...

With so much money changing hands over the Internet, credit card theft has become a tempting target for cyber criminals from every corner of the globe. So while credit cards may be the cornerstone to any successful e-commerce site, they may also be the biggest concern for many online retailers.

Risks Associated with Credit Cards

While great strides have been taken to help protect against credit card fraud, retailers cannot afford to be complacent when it comes to credit card security. Although the life line of any e-commerce site, the ability to process credit cards also comes with a number of risks.
In order to process credit card payments, the retailer must employ an application on their web site that can collect, process, and often store the credit card data in order to complete the transaction. Like any other web application, those that handle credit card transactions are threatened by a number of vulnerabilities such as:

• SQL Injection
• Cross-Site Scripting
• Path Traversal
• Session Hijacking
• Malware (Drive-by downloads)

Unlike the early days of e-commerce where an attacker had to have a certain degree of programming skill to carry out a successful attack, the use of large armies of bots have made it easy for an attacker with a minimal amount of skill to launch a large scale, coordinated attack against multiple retail web sites to harvest thousands of credit cards.

Credit Card Theft

Just a few short years ago over 130 million credit and debit cards were stole by Albert Gonzalez that cost Heartland Payment Systems $12.6 million. Prior to this, Gonzalez successfully exploited vulnerabilities in the TJX (TJ Maxx) network to harvest over 45 million cards from them and other retailers causing losses that exceeded $70 million due to fraud and a lawsuit filed against TJX by over 300 banks. The vulnerability that gave him and his crew access to the credit card data: SQL Injection.

Credit Card Fraud

One of the most worrisome issues when dealing with credit cards is a chargeback. These occur when a buyer disputes a charge. In cases where fraud is suspected, the credit card company almost always sides with the buyer leaving the merchant to take the loss, not the credit card company itself. In addition to lost revenue, some companies issue fees against a merchant when a fraudulent transaction is recorded on their site. Companies who are found to have too many chargebacks may even find that the credit card company will terminate the retailer’s ability to accept that card any longer.

PCI Compliance Issues

To combat the fraud and theft, five different credit card security programs merged to form the Payment Card Industry Security Standards Council (PCI SSC) in 2004. The intent of these companies, American Express, Discover Financial Services, JCB, MasterCard Worldwide and Visa International, was to provide additional protection to card issuers making sure that all merchants meet basic levels of security when storing, processing, and transmitting cardholder data.
The PCI standards are required of both online retailers and brick and motar shops alike. Some of the requirements that merchants are expected to abide by include:

• Build and maintain a secure network
• Protect cardholder data
• Maintain a vulnerability management program
• Implement strong access control measures
• Regularly monitor and test networks
• Maintain an information security policy

Companies that fail to comply with the PCI compliance standards risk losing the ability to process credit card payments and may be subjected to audits and fines.

Loss of Business

Aside from the loss due to chargebacks, there are often legal fees and other fines that a company faces if they have allowed credit card data to be stolen from their site. While these often have a significant impact on a company’s revenue, once shoppers have it in their mind that their credit card may not be safe when shopping sales are sure to plunge. Brand damage after a data breach is often worse for the bottom line than any combination of fees and fines.

Web Applications

With the application layer being the soft spot that many cyber criminals choose to concentrate their attacks on, the PCI Data Security Standards specifically address what a Web Site needs to do in order to properly protect its web applications.
In what is known as requirement 6.6, web site owners who process credit cards are given two options for compliance. Option one requires a code review to be done by an internal employee or a trusted third-party source and must consist of one of the four methods:

1. Manual review of application source code
2. Proper use of automated application source code analyzer (scanning) tool
3. Manual web application security vulnerability assessment
4. Proper use of automated web application security vulnerability assessment (scanning) tools

Code Reviews

Code reviews are a surgical approach to protecting web applications against attacks that can compromise credit card data. They involve a reviewer, or team of reviewers, going through an application’s code looking for possible vulnerabilities. While on the surface they may seem like the ideal way to approach PCI compliance, they are a costly approach that is not without drawbacks.
As with anything that involves human eyes, there is the possibility that something may be missed due to any number of reasons: negligence, ignorance, or a simple mistake. Alongside the possibility of human error, code reviews protect against known vulnerabilities. Once a code review is complete, future exploits may be found that were unknown at the time of the review. Add to this the fact that often times, vulnerabilities found in code reviews are not adequately patched and it is easy to see where a code review alone is not always the best solution.

Web Application Firewalls

The second option given by the PCI DSS allows for a company to implement a web application firewall solution in place of regular code reviews. A web application firewall, either a hardware appliance or software solution, is placed in between the client end point and the web application. Unlike traditional firewalls and intrusion prevention systems, web application firewalls, or WAFs, understand the application layer logic that is necessary to protect cardholder data.
Web application firewalls protect against the unknown threats as well. With a WAF, all web layer traffic is inspected looking for packets that are meant to exploit known vulnerabilities as well as patterns that may suggest a zero-day exploit is being launched against the application. This works to prevent attacks that will not be found in a code review alone.
Properly configured, web application firewalls protect against:

• Path Traversal Vulnerabilities
• Known worms
• Remote Command Execution
• Probe
• Denial of Service attacks
• Compromised servers
• Cross-Site Scripting
• SQL Injections

... and many more threats that can compromise credit card data.

The Need to Avoid Attacks

When it comes to protecting your customers’ credit card data from cyber criminals, finding the right solution needs to be a top priority, but it also needs to be one that your company can afford. Entering in to a code review, it is almost impossible to accurately gauge the total cost as resources must be spent to engage in the code review and then, it is necessary to dedicate manpower and money to patching any vulnerabilities found.

110,000 Credit Card Numbers Stolen in Tour Company Web Server Hack

 

According to a new Data Breach Investigations Report from global comms and IT provider Verizon ... read more ...

(WEB HOST INDUSTRY REVIEW) -- New York City bus tour company CitySights NY (www.citysightsny.com) announced earlier this month that a SQL injection attack on its web server compromised about 110,000 credit card numbers.
Although the breach happened on September 26, it was discovered a month later on October 25 when a web programmer noticed the unauthorized script.
The breach became public on December 9 when a letter sent to New Hampshire Attorney General Michael Delaney from CitySight's parent company, Twin America, was posted online. Around 300 New Hampshire residents were among those affected by the attack.
In the letter, Twin America suggests the Payment Card Industry (PCI) guidelines for storing card data were not being met.
The database held customer financial data, including the customer's name, address, email address and credit card information. Included in the credit card information was the expiration date and card verification value (CVV2) data.
With this additional credit card information, Twin America was in violation of PCI regulations on data retention, which bans retailers from permanently storing the CVV2 data because it makes it much easier to create fraudulent transactions when combined with the other card information.
Twin America says in the letter that it has taken measures to improve its data security. These steps include: changing all administrative level passwords, limiting the access to the administration panel and the server to a handful of pre-approved IP addresses, patching scripting vulnerabilities and setting up an applications firewall, and reconfiguring its systems so future transactions are processed without storing credit card data.
Twin America has sent breach notification letters to the affected customers, offering them one-year free membership with a credit monitoring service and a coupon with a 50 percent discount for one of their tours.
Several reports suggest Twin America still has security improvements to make however, noting that the coupon code published in the breach notification letter was 012345.

CWE/SANS Top 25

With the release of the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors came a push to hold software developers to be held liable for any insecure code they write.

 

Alan Paller, director of research for the SANS Institute commented that "wherever a commercial entity or government agency asks someone to write software for them, there is now a way they can begin to make the suppliers of that software accountable for [security] problems."
Put in place to protect the buyer from liability, these efforts are also guided at producing secure code from the very beginning since vendors won’t be able to charge for fixing vulnerabilities found in their software.

Compiling the list

The Most Dangerous Programming Errors is a list compiled yearly by the Common Weakness Enumeration, a community initiative sponsored by the US Department of Homeland Security and the MITRE corporation, and the SANS Institute. Drawing from an international pool of approximately 40 software security experts from businesses, governments, and universities, the Top 25 are created by building from the previous year’s list through a private discussion board. Once the threats discussed were evaluated by the research team and the list was narrowed down to 41 entries. These entries were then rated according to two metrics: prevalence and importance and the 25 with the highest ratings were selected to the list. The ratings for prevalence were:

• Widespread - the weakness was encountered more frequently than most others
• High - the weakness is often encountered
• Common - the weakness is periodically encountered
• Limited - rarely is the weakness encountered

When looking at the importance of a threat, the ratings were:

• Critical - when addressing the weakness, it should be done as quickly as possible taking resources away from other tasks if necessary
• High - the weakness should be addressed as quickly as possible but not as urgently as a critical weakness
• Medium - these weaknesses should be addressed only after all high and critical weaknesses have been fixed
• Low - fixing the weakness is not urgent or important

The Top 25

In addition to ranking the Top 25 weaknesses, the report broke them down in to three categories: Insecure Interaction Between Components, Risky Resource Management, and Porous Defenses. The following table displays the rank, score, weakness, and category it falls under.

Rank	Score	Weakness	Category
1	346	Failure to preserve web page structure (Cross-site scripting)	Insecure interaction between components
2	330	Improper sanitization of special elements used in a SQL command (SQL injection)	Insecure interaction between components
3	273	Buffer copy without checking the size of input (Classic buffer overflow)	Risky resource management
4	261	Cross-site request forgery	Insecure interaction between components
5	219	Improper access control (Authorization)	Porous defenses
6	202	Reliance on untrusted inputs in a security decision	Porous defenses
7	197	Improper limitation of a pathname to a restricted directory (Path traversal)	Risky resource management
8	194	Unrestricted upload of a file with dangerous type	Insecure interaction between components
9	188	Improper sanitization of special elements used in an OS command (OS command injection)	Insecure interaction between components
10	188	Missing encryption of sensitive data	Porous defenses
11	176	Use of hard-coded credentials	Porous defenses
12	158	Buffer access with incorrect length value	Risky resource management
13	157	Improper control of filename for include/require statement in PHP program (PHP file inclusion)	Risky resource management
14	156	Improper validation of array index	Risky resource management
15	155	Improper check for unusual or exceptional conditions	Risky resource management
16	154	Information exposure through an error message	Risky resource management
17	154	Integer overflow or wraparound	Insecure interaction between components
18	153	Incorrect calculation of buffer size	Risky resource management
19	147	Missing authentication for critical function	Porous defenses
20	146	Download of code without integrity check	Risky resource management
21	145	Incorrect permission assignment for critical resource	Porous defenses
22	145	Allocation of resources without limits or throttling	Risky resource management
23	142	URL redirection to untrusted site (Open redirect)	Insecure interaction between components
24	141	Use of a broken or risky cryptographic algorithm	Porous defenses
25	138	Race condition	Insecure interaction between components

Dealing with Weaknesses

If developers are expected to ensure that their code is void of any weakness listed in the Top 25, they need to a) know how to identify the weakness and b) know how to prevent it. The report further breaks down those making the list and provides a detailed description for each weakness. These descriptions are broken down for the developer, providing a Summary that provides the weakness prevalence rating, a rating for the remediation cost, the attack frequency, the consequences of the weakness being exploited, how easy it is to detect the weakness, and how aware attackers are that the weakness exists. Following the summary is a discussion that provides the developer with a quick description of how an attack is carried out against the weakness and a sequence of prevention techniques to help developers avoid making such mistakes in their code.

What about OWASP

In developing their Top 25 list, CWE/SANS included a comparison to the OWASP Top Ten making a clear statement of the importance of OWASP’s list while also recognizing distinct differences between the two. Most clearly defined is that the OWASP Top Ten deals strictly with vulnerabilities found in web applications where the Top 25 deals with weaknesses found in desktop and server applications as well. A further contrast is seen in how the list is compiled. OWASP giving more credence to the risk each vulnerability presents as opposed to the CWE/SANS Top 25 that included the prevalence of each weakness. This factor is what gives Cross-site scripting the edge in the Top 25 as it is ranked number 1 while OWASP has it ranked at number 2.

Working with the Top 25

Pushing to make the Top 25 a checklist for developers to use to avoid lawsuits seems like the panacea for all programming vulnerabilities to those who support adopting such standards. Opponents claim that it will result in costlier software. Neither addresses what happens in the event of a zero-day attack. With an estimated 78% of all vulnerabilities being found in web applications, the likelihood of falling victim to an unknown threat is high.
So what happens if XYZ software abides by the Top 25 but weeks after deploying a new application, they are hit by an unknown threat? Is XYZ liable? Or is the buyer? And what if the buyer fails to protect the application? If the code is attacked as a result of their failure to secure other resources, where does the blame lie?
In my opinion, this has already been answered and is put into practice daily. Merchants who want to accept credit cards must comply with PCI standards that require either a code review or the deployment of a web application filter. Taking either route insures compliance but the recommendation is to make use of both solutions. Code review, which would help address Top 25 weaknesses, helps the developer indentify weaknesses and address them before releasing the application to the marketplace. Building secure code from the beginning is always a best practice to be followed. Combining this with the protection a web application firewall provides a line of defense against unknown vulnerabilities to stave off potential zero-day threats.

PCI DSS Compliance

Web applications have become a "soft spot" for cybercriminals intent on stealing credit card information. To combat the proliferation of online fraud, the Payment Card Industry (PCI) Security Standards Council (SSC) was formed to make sure that merchants who accept credit cards meet minimum security levels in how they accept, process, and transmit credit card information.

Security experts suggest senior federal bureaucrats are playing with fire by sending sensitive government information .These minimum standards came to be known as the PCI Data Security Standards (DSS).When it comes to Ecommerce, merchants make use of web applications to handle credit cards. Protecting these web applications to comply with PCI compliance requirements may present technical and business challenges, depending on the existing network architecture and chosen solution. In many cases, the path to PCI compliance can entail expensive consulting engagements and massive infrastructure overhauls.

What is PCI DSS?

The Payment Card Industry Data Security Standard (PCI DSS) was developed by payment brands including American Express, Discover Financial Services, JCB International, MasterCard Worldwide and Visa. International. It defines a set of 12 requirements for enhancing payment account data security to include the policies, tools, and controls needed to protect cardholder data.
Compliance with the PCI DSS is not optional, nor are small companies exempt. Any company that processes or stores credit card data is required to comply with these requirements. Even a small business who process only one credit card sale a year must implement set of security mandates in order to ensure the safety of cardholder information such as account data, credit card numbers, customer names, and contact information to protect the cardholder from being exposed to unauthorized users.

Why is PCI Compliance Important?

The infamous TJX security breach disclosed in 2007 is a good example of what can happen to companies that do not have the proper security measures in place. This breach resulted in 94 million accounts being compromised with losses exceeding $70 million due to fraud.
According to court documents, the consultant retained by TJX to investigate the breach found that the company had failed to comply with nine of the twelve security measures mandated by the Payment Card Industry (PCI) Data Security Standard (DSS).
"There were ... many deficiencies and PCI DSS violations which the attacker was able to exploit in order to compromise data from the TJX network," the unnamed consultant stated. (source: Security Focus)
The monetary loss due to fraud was not the only cost of this security breach. A lawsuit was filed against TJX by over 300 banks and trust in the brand had taken a substantial downturn among customers.

PCI DSS Levels

PCI DSS affects merchants that handle credit card information from cards issued by any of the founder brands. It is most relevant to online merchants that process and store payment account data online.
For the majority of organizations, the standards set forth by Visa's CISP and MasterCard's SDP programs cover the qualifications for assigning both a merchant level and compliance level, along with incorporating PCI DSS.
The merchant level is based on transaction volume for the organization. The validation compliance level is based on the merchant level. It includes the validation actions and who needs to carry out these actions in order to be PCI DSS compliant.

1. Level One: Visa U.S.A. and MasterCard World Wide transactions totaling 6 million and up, per year, and any merchants who experienced a data breach. Level one merchants are required to have an annual on-site compliance assessment performed by a third-party Qualified Security Assessor (QSA). In addition they are required to have external network security scans performed quarterly by a certified third-party Approved Security Vendor (ASV).
2. Level Two: Visa and MasterCard transactions totaling 1 million to 6 million per year. Level Two merchants are required to complete the PCI DSS Self Assessment Questionnaire annually and carry out a quarterly network security scan with an ASV.
3. Level Three: Visa and MasterCard e-commerce transactions totaling 20,000 to 1 million per year. Level Three merchants are required to complete the PCI DSS Self Assessment Questionnaire annually, and carry out a quarterly network security scan with an ASV.
4. Level Four: Visa and MasterCard e-commerce transactions totaling up to 20,000 per year. Level Four merchants are required to complete the PCI DSS Self Assessment Questionnaire annually, and carry out a quarterly network security scan with an ASV.

Web Application Compliance

Since web applications account for such a high percentage of vulnerabilities, the PCI DSS specifically addresses them in Requirement 6.6. This states that organizations are to ensure the highest level of application security.
“Forensic analyses of cardholder data compromises have shown that web applications are frequently the initial point of attack upon cardholder data, through SQL injection in particular.
The intent of Requirement 6.6 is to ensure web applications exposed to the public Internet are protected against the most common types of malicious input.”
There are two methods that a company can take in order to be in compliance with PCI DSS 6.6: yearly code reviews or a web application firewall.

Code Review

The first alternative may provide a high level of security, but can end up being an extremely costly solution. Organizations typically use several applications and add new ones all the time. The total cost of code reviews is comprised of the review itself, and the effort needed to fix the vulnerabilities it identifies. The IT team will need to prepare the code for review, and be available for queries and support to the reviewers. After the consultants submit a vulnerabilities report, your organization will need to schedule fix and test cycles to make sure the changes work as expected.
This “find, fix, and test” cycle does not always find all of the vulnerabilities in an application, resulting in more cycles. What’s more, Quality Assurance will need to verify that security fixes does not interfere with business processes. Therefore, any organization choosing this alternative should allocate the following resources yearly:

• Services by application security specialists
• IT resources to manage the code review process
• Development resources for eliminating vulnerabilities
• QA resources
• R&D risks entailed by development of security fixes and features

More importantly, a code review finds vulnerabilities that are known to the reviewer at the time of the review. Zero-day vulnerabilities that have yet to be discovered are likely to be missed unless the code reviewer is highly proactive and goes well beyond their required duties.
Thus, the second alternative — deploying a web application firewall — becomes a more attractive solution as it provides a one-time compliance solution.

The Web Application Firewall Solution

Web application firewalls focus on protecting against, rather than identifying, vulnerabilities. They perform a deep packet inspection of incoming traffic to detect threats, thereby creating a security layer in front of the application itself.
This approach offers the following advantages:

• One time investment in PCI compliance
• A solution for security problem without development effort
• Suitable for 3rd party applications and components where code is not readily accessible

Why Web Application Security?

Presence on the Internet involves dealing with an ever-shifting landscape.

Basically, an attacker inputs a malicious script into a web site. This can be in a forum, comment section, or any other input area. When victims visit that web site, they only need to click on that script to start the exploit.
A few facts about cross-site scripting attacks that you should be aware of are:

• Every month roughly 10-25 XSS holes are found in commercial products and advisories are published explaining the threat.
• Websites that use SSL (https) are in no way more protected than websites that are not encrypted. The web applications work the same way as before, except the attack is taking place in an encrypted connection.
• XSS attacks are generally invisible to the victim.
• All Web servers, application servers, and Web application environments are susceptible to cross-site scripting.

Cross Site Scripting (XSS) Attacks

Cross-site scripting has been at the top of both the OWASP Top Ten list and the CWE/SANS Top 25 repeatedly. Some reports show cross-site scripting, or XSS, vulnerabilities to be present in 7 out of 10 web sites while others report that up to 90 percent of all web sites are vulnerable to this type of attack. Why are so many sites at risk? Because cross-site scripting attacks are so easy to perform.

Risks Associated with Cross-Site Scripting

Attackers are lured to XSS exploits because how easy they are to perform, but they also know to follow the money. Attacking a web site through a cross-site scripting vulnerability can be quite profitable for the attacker who knows how to harness this type of exploit.
Without proactive Web application security in place to stop XSS attacks, you leave your site vulnerable to:

• User accounts being stolen through session hijacking (stealing cookies) or through the theft of username and password combinations
• The ability for attackers to track your visitors web browsing behavior infringing on their privacy
• Abuse of credentials and trust
• Keystroke logging of your site’s visitors
• Misuse of server and bandwidth resources
• The ability for attackers to exploit your visitor’s browser
• Data theft
• Web site defacement and vandalism
• Link injections
• Content theft

Web sites that have been exploited using XSS attacks have also been used to:

• Probe the rest of the intranet for other vulnerabilities
• Launch Denial of Service attacks
• Launch Brute Force attacks

Preventing Cross-Site Scripting Attacks

With dotDefender web application firewall you can avoid XSS attacks because dotDefender inspects your HTTP traffic and determines if your web site suffers from cross-site scripting vulnerabilities or other attacks to stop web applications from being exploited.
Architected as plug & play software, dotDefender provides optimal out-of-the-box protection against cross-site scripting, SQL Injection attacks, path traversal and many other web attack techniques.
The reasons dotDefender offers such a comprehensive solution to your web application security needs are:

• Easy installation on Apache and IIS servers
• Strong security against known and emerging hacking attacks
• Best-of-breed predefined security rules for instant protection
• Interface and API for managing multiple servers with ease
• Requires no additional hardware, and easily scales with your business

How does an attacker exploit a cross-site scripting vulnerability?

Before a web site can be compromised, an attacker needs to find applications that are vulnerable to XSS vulnerabilities. Unfortunately, most web applications, both Free/Open Source Software and commercial software, are susceptible. Attackers simply perform a Google search for terms that are often found in the software. Using search bots to automate this process means an attacker can find thousands of vulnerable web sites in minutes.
Once a vulnerable web site is discovered, the attacker then examines the HTML to find where the exploit code can be injected.

Coding the exploit

After this has been determined, the attacker then begins to code the exploit. There are three types of attacks that can be used:

1. Stored (persistent) attacks: Injected malicious code is stored on a target server such as a bulletin board, a visitor log, or a comment field. When interacting with the target server, an end-user inadvertently retrieves and executes the malicious code from the server.
2. Reflected attacks: The end-user is tricked into clicking a malicious link or submitting a manipulated form. The injected code is sent to a vulnerable web server that directs the cross-site attack back to the user’s browser. The browser then executes the malicious code, assuming it comes from a trusted server.
3. DOM-based attacks: The attack script is based on the same page's DOM (document object model), enabling it to manipulate and interrogate it. In this type of exploit, remote execution is enabled allowing the attacker to execute malicious code on the victim's computer.

After the code has been written, it is then injected into the target site.

Reap the rewards

Now that the script has been injected into the vulnerable site, the attacker can now begin to reap the rewards. If the intent of the XSS attack was to steal user authentication credentials, usernames and passwords are now collected. For attacks that center around keystroke logging, the attacker will begin to receive the logged results from the victims. If the intent was to inject spam links into a well trusted site, then the attacker will begin to see increased activity on their sites due to higher traffic and higher search engine results.
If the attack was successful, the attacker will often replicate it on other sites to increase the potential reward.

The Need to Avoid Cross-Site Scripting Attacks

Cross-site scripting not only costs businesses in stolen data, but also by harming their reputation. Owners who work hard to build themselves as trusted site to deliver content, services, or products often find themselves hurt when loyal visitors lose trust in them after an attack. Visitors whose data is stolen or find their computers infected as the result of an innocent visit to your web site are hesitant to return even if assurances are made that the site is now clean.
Even if a vulnerable site is fixed, sites that contained malicious code from an XSS exploit are usually flagged by Google and other search engines as a result. Resources spent in time and effort to restore a solid reputation with the search engines is an added cost that most web site owners never figure on.
The threat posed by cross-site scripting attacks is not solitary. Combined with other vulnerabilities like SQL injections, path traversal, denial of service attacks, and buffer overflows the need for web site owners and administrators to be vigilant is not only important but overwhelming.

Protect Yourself from Cross-Site Scripting Attacks

dotDefender's unique security approach eliminates the need to learn the specific threats that exist on each web application. The software that runs dotDefender focuses on analyzing the request and the impact it has on the application. Effective web application security is based on three powerful web application security engines: Pattern Recognition, Session Protection and Signature Knowledgebase.
The Pattern Recognition web application security engine employed by dotDefender effectively protects against malicious behavior such as SQL Injection and Cross Site Scripting. The patterns are regular expression-based and designed to efficiently and accurately identify a wide array of application-level attack methods. As a result, dotDefender is characterized by an extremely low false positive rate.
What sets dotDefender apart is that it offers comprehensive protection against cross-site scripting and other attacks while being one of the easiest solutions to use.

SQL Injection Attacks

Coming in at number one in the OWASP Top Ten Most Critical Web Application Vulnerabilities are injection attacks, and SQL Injection vulnerabilities are the most common and most dangerous in this category. SQL injection is a technique that exploits vulnerable web sites by inserting malicious code into the database that runs it.

What makes the threat of SQL injection attacks so dangerous is the ease in which they can be launched and how many web sites are vulnerable to them.
Attackers often use large botnets to systematically seek out vulnerable web sites to attack with little work being done on their part. Pair this with the fact that the number of sites vulnerable to this type of attack grows each year and it is clear to see why it remains at the top of the most critical vulnerabilities.

Risks Associated with SQL Injection

Even with the ease that an automated SQL injection attack can be carried out, if the attackers stood to gain nothing this threat would soon disappear. Unfortunately, those who successfully compromise vulnerable web sites can find that this vulnerability can be quite profitable as they give the attacker access to the database so information can be sold or data can be deleted. More advanced techniques can also be used to give the attacker unrestricted access to the system through a backdoor. SQL injection can also be used in tandem with other exploits, such as cross-site scripting, to manipulate how data is displayed to a web site’s visitors.
Not preventing SQL Injection attacks leaves your business at great risk of:

• Changes to or deletion of highly sensitive business information.
• Steal customer information such as social security numbers, addresses, and credit card numbers.
• Financial losses
• Brand damage
• Theft of intellectual property
• Legal liability and fines

Preventing SQL Injection Attacks

With dotDefender web application firewall you can avoid SQL injection attacks because dotDefender inspects your HTTP traffic and determines if your web site suffers from SQL Injection or other attacks stopping identity theft and preventing data leaks from web applications.
Architected as plug & play software, dotDefender provides optimal out-of-the-box protection against SQL Injection attacks, cross-site scripting, website defacement and many other web attack techniques.
The reasons dotDefender offers such a comprehensive solution to your web application security needs are:

• Enterprise-class security against known and emerging hacking attacks
• Solutions for Hosting, Enterprise and SMB/SME
• Supports multiple platforms and technologies - IIS, Apache, Cloud ...
• Central Management console for easy control over multiple dotDefender installations
• Open API for integration with management platforms and other applications

How does an attacker compromise your SQL server?

Before a web site can be compromised, an attacker needs to find applications that are vulnerable to SQL injection using queries to learn the SQL application methods and its response mechanisms.
The attacker has two ways to identify SQL injection vulnerabilities:

1. Error messages: the attacker constructs the correct SQL syntax based on errors messages propagated from the SQL server via the front-end web application. Using the errors received, the hacker learns the internal SQL database structure and how to attack by injecting SQL queries via the Web application parameters.
2. Blindfolded Injection: this technique is utilized by hackers in situations where no error messages or response content is returned from the database. In these cases, the attacker lacks the ability to learn the backend SQL queries in order to balance the SQL injection query. In the lack of database content output within the Web application, the attacker is also challenged with finding a new way of retrieving the data.

Identifying the database

When the attacker knows how each database is reacting he or she can identify the database type and the server that is running it.
There are several techniques the attacker uses to identify database objects in a SQL statement.

1. Using a concatenation string:
   select f1+f2
   from t1
2. Using a semicolon or cash sign ($)

Compromising the SQL server

Once the attacker has all information he can build the exploit code.
Some techniques used to execute SQL Injection attacks are:

• Terminating queries using quotes, double-quotes, SQL comments
• Using stored procedures
• Database manipulation commands such as TRUNCATE, DROP
• Using CASE WHEN, EXEC to run nested queries
• Utilizing SQL injection to create Buffer Overflow attacks within the database server
• Delivering SQL queries via XML and Web Services
• Blindfolded SQL Injection techniques:
  • Blindfolded injection techniques using Boolean queries and WAITFOR DELAY
  • Comparison queries using commands such as BETWEEN, LIKE, ISNULL
• IDS signature evasive SQL Injection techniques:
  • Using CONVERT & CAST commands to mask the attack payload Using Null bytes to break the signature pattern
  • Using HEX encoding mixtures
  • Using SQL CHAR() to represent ASCII values as numbers

For example, the attacker decides to go with a basic attack using:
1 = 1--
What happens when this is entered into an input box is that the server recognizes 1 = 1 as a true statement. Since -- is used for commenting, everything after that is ignored making it possible for the attacker to gain access to the database. You can see precisely how this attack works on our SQL injection example page.

The Need to Avoid SQL Injection Attacks

SQL injection techniques have been around for over 10 years now, but recent years have seen a dramatic increase in both number of attacks and the extent of damage caused by them. In fact, a sweep of attacks in the second quarter of 2008 alone resulted in over 500,000 exploited web pages that were compromised to deliver password-stealing malware to users' computers. In more recent studies, security firms report attempted attacks reaching totals of 450,000 per day.
The tragedy is that these threats can be mitigated, or even prevented, with the proper tools and knowledge.
The attacker identifies vulnerabilities and obtains database access SQL (Structured Query Language) provides an interface to facilitate access to and interaction with a database. A database usually stores data in tables and procedures.
SQL Injection is a security exploit method in which the attacker aims at penetrating a back-end database to manipulate, steal or modify information in the database. The SQL Injection attack method exploits the Web application by injecting malicious queries, causing the manipulation of data. Almost all SQL databases and programming languages are potentially vulnerable and over 60% of websites turn out to be vulnerable to SQL Injection.
The threat posed by SQL injection attacks are not solitary. Combined with other vulnerabilities like cross-site scripting, path traversal, denial of service attacks, and buffer overflows the need for web site owners and administrators to be vigilant is not only important but overwhelming.

Protect Yourself from SQL Injection Attacks

dotDefender's unique security approach eliminates the need to learn the specific threats that exist on each web application. The software that runs dotDefender focuses on analyzing the request and the impact it has on the application. Effective web application security is based on three powerful web application security engines: Pattern Recognition, Session Protection and Signature Knowledgebase.
The Pattern Recognition web application security engine employed by dotDefender effectively protects against malicious behavior such as SQL Injection and Cross Site Scripting. The patterns are regular expression-based and designed to efficiently and accurately identify a wide array of application-level attack methods. As a result, dotDefender is characterized by an extremely low false positive rate.

What types of SQL Injection attacks does dotDefender block?

dotDefender blocks against various SQL Injection techniques including, but not limited to:

• Terminating queries using quotes, double-quotes, SQL comments
• Stored procedure names
• Comparison queries using commands such as BETWEEN, LIKE, ISNULL
• Database manipulation commands such as TRUNCATE, DROP
• Reserved words such as CASE WHEN, EXEC
• Blindfolded injection techniques such as Boolean queries and WAITFOR DELAY
• Database-unique attacks relating to Oracle, MySQL, MS-SQL
• Signature evasion techniques such as using CONVERT & CAST
• Buffer overflow attacks via SQL Injection
• XML and Web-Services encapsulating SQL Injection techniques
• Null byte signature evasion
• HEX encoding mixtures for signature evasion
• Using SQL CHAR() for signature evasion
• Zero-day protection against MS-SQL stored procedure attacks such as MS08-040

What sets dotDefender apart is that it offers comprehensive protection against SQL injection and other attacks while being one of the easiest solutions to use.