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.