The Importance to Also Scan Trusted Sections of your Web Applications

Many people only run external or “unauthenticated” web application security scans; they do not audit the admin portal, or user portal of most business web applications which most of their own employees use. Be it for a PCI DSS compliance, business partner requirements, or internal audit, the need is to only see what can be seen (and exploited) from the outside world.

Why Authenticated Web Application Security Scans?

However, more and more people – namely savvy auditors, developers, and IT professionals – are performing authenticated vulnerability scans of their web applications; i.e. scanning the web portals that are typically used only by trusted users such as employees and freelancers and not accessible to the public. Scanning of such trusted web portals is becoming more important simply because many of the successful hack attacks typically happen from the inside of the trusted network because an insider was involved, or a malicious user managed to gain access to a trusted user account. In that case by scanning authenticated sections of your web applications, identifying vulnerabilities and remediating them you are also improving your containment policies.

Findings that are often identified during authenticated web vulnerability scans include:

• SQL injection
• Session fixation
• Cross-site request forgery (CSRF)
• Privilege escalation
• Command injection

Typically during a web application security scan one can also often identify vulnerabilities associated with the web application login system or even other user accounts. All of these low hanging fruit type web application vulnerabilities can be easily exploited by malicious users to further penetrate the network and generate more damage.

What to Look For in Authenticated Web Security Scans

Authenticated web vulnerability scans are not completely hands-off. You’ll need to monitor the scanner to ensure that authentication and crawling are working properly. As you can imagine, it pays to know your application – the pages and the workflows. This is especially beneficial when configuring login macros and adjusting the overall scope of your scan. If, during your authenticated web vulnerability scans, you see that the scanner is not:

• Crawling all pages
• Executing specific workflows
• Finding different flaws
• Taking any longer than unauthenticated scans

…then you’re probably not getting a good authenticated scan. It could be that your scanner is not properly logging in because of a poorly configured login macro, or the session is not well kept. It could also be that the user account or accounts you configured the scanner to login with are locked. User accounts and their management policies, such as account lockouts etc tend to be a big problem for automated scans. So be sure to keep an eye on these areas when running your authenticated web application security scans. Otherwise, you might have a false sense of security that your entire web application has been properly vetted.

Test Different User Roles in Authenticated Web Security Scans

Another thing you’ll want to keep in mind when running authenticated web vulnerability scans is the different user roles in your application. Each user role is going to have unique permissions/privileges within the web application which likely means that the web application security scanner will uncover unique vulnerabilities for each account you test with.

Start with Administrative Roles

If you don’t have the time or ability to test every user role, at least start out testing the user role that’s most representative of your user base. Ideally you’ll want to test the highest level admin or supervisor role. The administrative accounts are usually the most targeted accounts and if these user accounts are ever compromised, it will likely present the greatest level of opportunity for exploitation. Yet, still, lower-privilege accounts might have access to pages and workflows that others do not and, therefore, vulnerabilities such as SQL injection might be unique to that role level.

The most important thing about authenticated web vulnerability scans is to ensure that you’re doing them. In the interest of time, effort, money, containment policies or whatever variables apply to your situation, you may not need to run authenticated scans every time you test. Just make sure you’re running them on a periodic and consistent basis.

International Pension Administration and Benefits Company, Morneau Shepell, uses Netsparker to automatically scan over 600 websites a month.

Founded in the eighties as SOBECO, the company merged with Morneau in 1995 to become Morneau Sobeco. Later in 2006 Morneau Sobeco acquired Shepell FGI to become Morneau Shepell. Today Morneau Shepell serves more than 8,000 clients, ranging from small businesses to some of the largest corporations and associations in North America.

The Web Applications

Their websites and web applications are built with .Net framework and run on Microsoft IIS servers. Web applications are used by employees and business partners to gain access to the personal accounts and information of their client’s employees for making pension investments and payments.

Why Use Netsparker Web Application Security Scanner?

Prior to using Netsparker, the company had used Nessus as their primary web application security scanner. Though as Security Analysts Mihai Petre highlights “existing tools used for testing published websites and web applications such as Nessus are not reliable.  With the ever growing number of published websites, sorting through the scan results and verifying the findings was both a frustrating and a time consuming process.”

“We started looking for a more efficient solution that could help us automated most of the tasks, and Netsparker was the obvious choice because it automatically verifies identified vulnerabilities. Therefore our team didn’t need to allocate time in verifying the scanner’s findings,” continued Mihai Petre.

Netsparker is now being used to carry out monthly scheduled web application security scans, using credentials and also daily ones when the need arises. “We have been using Netsparker for over three years at Morneau Shepell, since version 2 was released. We are very happy with Netsparker and as long as they keep on frequently updating it, we will stick to it” said Mihai Petre.

Damage Limitation

Should a web application be hacked and sensitive data is leaked or stolen, the company could suffer severe financial and regulatory compliance problems.  When Morneau Shepell started using Netsparker 3 years ago, many websites needed improvements in mitigating SQL Injections and Cross-site Scripting (XSS) vulnerabilities.

Using Netsparker they identified and confirmed particular cases where sites were vulnerable and quickly deployed fixes. Now the security team is confident that their web applications are secure, “Now the scanning reports only include IIS configurations problems, detected as low alerts. Thanks to Netsparker we identified and closed all critical security vulnerabilities”, Mihai Petre affirmed.

Netsparker Endorsement

“When you have to scan hundreds of web applications and identify exploitable vulnerabilities on all of them, Netsparker is THE essential easy to use tool that provides professional reports with clear explanation and steps to remedy them”, attested Mihai Petre, Security Analyst.

About Moreau Shepell

Established in 1966, Morneau Shepell serves more than 8,000 clients, ranging from small businesses to some of the largest corporations and associations in North America. With approximately 3,000 employees in offices across North America, Morneau Shepell provides services to organizations across Canada, in the United States and around the globe. Morneau Shepell is a public-traded company on the Toronto Stock Exchange (TSX: MSI).

About Netsparker Web Application Security Scanner

Netsparker Web Application Security Scanner is an industry leading automated web vulnerability scanner developed by Netsparker Ltd. Netsparker management and engineers have more than a decade of experience in the web application security industry that is reflected in their product. Netsparker is a very easy to use web application security scanner that automates most of the web application security scanning. An out of the box installation of Netsparker is able to scan a wide variety of web applications, therefore web security experts, penetration testers and QA engineers do not need to spend countless amount of hours tweaking and configuring the software. Netsparker is revolutionising web application security by being the only web application security scanner to automatically verify detected web vulnerabilities, thus reporting no false positives. Netsparker is used by world renowned companies such as Samsung, NASA, Skype, ING and Ernst & Young.

Netsparker Version 3.1 New Features and Improvements

Everyone in our team is really happy to announce the release of Netsparker version 3.1. As you will see in these release notes, this new version is jampacked with new features, new functionality and new web application security checks. Most of the new security features are targeted to help penetration testers, web application security experts and developers do a better job in uncovering all type of vulnerabilities in all of the web applications they are securing, including modern Web 2.0 and HTML5 web applications.

This new version of Netsparker is also able to extract much more details about the target web application which if unnoticed could potentially help malicious hackers craft malicious attacks against the web application. Such information will enable Netsparker users to better understand the target web application so they can attack it better themselves and uncover all security issues. Following is the list of what is new and improved in Netsparker version 3.1.

JSON & XML Request Parsing and Injection Support

Netsparker is now able to launch advanced web security checks against web 2.0 applications by identifying, parsing and attacking HTTP request bodies which contain JSON and XML data. If the target web application uses JSON as its payload while performing AJAX requests, Netsparker will intercept that and attack each of the property values. A sample attack below shows that Netsparker performs a Command Injection attack to a parameter value in a JSON payload:

Per Scan Policy Settings

In Netsparker version 3 we introduced Scan Policies, enabling users to specify the type of vulnerabilities a web application should be checked for. In version 3.1 we went a step further by moving most of the global Netsparker settings to the Scan Policy editor. This allows you to create scan policies with different set of settings. For example if a  security consultant works with different customers and one of them requires the consultant to connect to a proxy while scanning their websites, the security consultant can create a new Scan Policy specifically for that customer with the required settings and load it up each time he needs to launch a scan, rather than reconfiguring such settings.

HTML5 Support

This new version of Netsparker now fully supports HTML5 web applications. The all new HTML5 engine allows Netsparker to properly crawl HTML5 web applications and identify all attack surfaces that could be susceptible to exploitable vulnerabilities.

Netsparker also detects improperly sandboxed or insecure inline frames. iframe sandboxing enables a set of extra restrictions for the content in the inline frame. When inline frame is sandboxed, the iframe content is treated as being from a unique origin and sandboxed content is re-hosted in the browser with the following restrictions:

• Plugins are disabled. Any kind of ActiveX, Flash, or Silverlight plugin will not be executed.
• Forms are disabled. The hosted content is not allowed to make forms post back to any target.
• Scripts are disabled. JavaScript is disabled and will not execute.
• Links to other browsing contexts are disabled. An anchor tag targeting different browser levels will not execute.
• Unique origin treatment. All content is treated under a unique origin. The content is not able to traverse the DOM or read cookie information.

When the sandbox attribute is not set or its value contains one or more of the below listed values for an external URL, Netsparker will report it:

• allow-same-origin will not force the unique origin for iframe contents.
• allow-top-navigation will allow iframe to navigate parent context. (e.g. change parent.location).
• allow-forms will allow forms submissions from inside iframe.
• allow-popups will allow popups.
• allow-scripts will allow malicious script execution.

Overall Netsparker will report to you anything that is wrong with the embedded iframe and also recommends several remediations.

New Knowledge Base Items

With the release of Netsparker 3.1 we are also introducing 4 new Knowledge Base nodes where Netsparker will report more findings about the target web application. Such information allows web application security professionals to better understand the web application they are scanning thus helping them do a more complete web application security audit. The 4 new Knowledge Base nodes are;

• Out of Scope Links: This node will list all the links which Netsparker skipped during a scan because of several reasons, such as link is matching one of the specified exclude patterns, link is on another domain and so on. A reason will also be listed for all links explaining why they are out of scan scope. This is also your one stop shop to find answers to your “Why did not Netsparker visit that page?” questions.
• Code Comments: In this node Netsparker will populate a list all the HTML, CSS and JavaScript comments extracted from the target website. should the comments contain sensitive keywords such as password, secret, admin, etc they will be highlighted since they might have been left by mistake and might be exposing sensitive data which could be used by malicious hackers to craft a hacking attack. The list of sensitive keyword matching patterns can be customized from settings per your needs.
  
• External Frames: This node will contain a list the frames identified on the target website which point to external locations. This piece of information would reveal any malicious frames placed on the target website without the knowledge of the author.
• Embedded Objects: This node will report all the embedded objects found in the target website, such as Flash movies, ActiveX objects, Java Applets, etc.

Automatic Detection of Cross-Site Request Forgery Vulnerability

The new version 3.1 of Netsparker will detect possible Cross-site Request Forgery (CSRF) vulnerabilities automatically during a web application security scan.

CSRF is an attack which forces an end user to execute unwanted actions on a web application in which the user is currently authenticated. With a little help of social engineering, for example by sending a malicious link via email or chat, the attacker may trick the victim into executing actions of the attacker's choosing. A successful CSRF attack can compromise end user data and operation in case of normal user. If the targeted victim is the administrator account, this can compromise the entire web application.

Netsparker is also capable of automatically detect forms which are not vulnerable to CSRF attacks, for example search forms, forms with CAPTCHA etc. This detection mechanism will eliminate false-positive cases.

Netsparker differentiates CSRF vulnerability in login forms as a separate issue.

Because the impact of this vulnerability is decreased significantly however it might still be dangerous in certain situations. In this kind of attack, the attacker will send a link containing html as simple as the following in which attacker's username and password is attached.

<form method="POST" action="http://honest.site/login">
  <input type="text" name="user" value="h4ck3r" />
  <input type="password" name="pass" value="passw0rd" />
</form>

<script>
  document.forms[0].submit();
</script>

When the victim clicks the malicious link, the form will be submitted automatically to the legitimate website and exploitation is successful. The victim will be logged in as the attacker and consequences will depend on the website behavior.

Example of CSRF Attack in Search History

Many sites allow their users to opt-in to saving their search history and provide an interface for a user to review the personal saved search history. Search queries may contain sensitive details about the user’s interests and activities and could be used by the attacker to craft an attack against the user to steal the user’s identity, or to spy on the user. Since the victim logs in as the attacker, the victim's search queries are then stored in the attacker’s search history, and the attacker can retrieve the queries by logging into his or her own account.

Example of CSRF Attack in Shopping Websites

Merchant sites allow their customers to save the credit card details in their online profile. In a login CSRF attack, when the user funds a purchase and enrolls the credit card, the credit card details might be added to the attacker's account should the CSRF attack be successful.

Other Notable New Features in Netsparker 3.1

• Added support for parsing cookies which are set by HTML meta tags.
• Ability to generate multiple reports using different templates from a scan result when using the command line interface.
• Vulnerability database updates such as version checks of the latest web application or web server can now be installed without the need to update the Netsparker installation.
• Significant improvements to the JavaScript / AJAX simulation result in faster and more accurate execution of code on pages with lots of HTML elements and JavaScript interaction.
• Scan Summary Dashboard now includes additional information while crawling and attacking pages. For example whether it is doing a HTTP request at the moment or analyzing the response. Attacking activity items now also include the current attack pattern that is being issued along with the scanning engine. The numbers next to engine and pattern names denotes the current and the total number of engines and patterns for this scan. Another enhancement in this area is Re-Crawling and Extra Confirmation phases will also show the current activity on this dashboard.
• In version 3.1 you can configure Netsparker to log all the HTTP requests and responses sent and received during a web security scan. These logs can be exported to Fiddler to further analyse the scan results and to get a better understanding of the web application behaviour.

Improvements in Netsparker 3.1

• Attack possibility calculation is improved
• Rendering in severity bar chart in scan summary dashboard is improved
• Added late confirmation support for Blind Command Injection engine
• DOM parser print dialog prevention improved
• Browser View tab now shows XML responses in a tree view
• Tweaked sleep tolerance value of time based engines
• Improved the impact sections of most of the vulnerability templates
• Improved LFI Exploitation which now is capable of better file content extraction and highlighting on text editor
• Form inputs listed under knowledge base are now grouped by their types
• Improved PHP Source Code Disclosure pattern
• Improved DOM parser to extract textarea elements
• Improved LFI Exploitation to cover case where LFI vulnerable page contains extra HTML tags
• Improved LFI confirmation patterns
• Improved XSS confirmation for Full URL and Full Query String attacks
• Optimized XSS confirmation phase to skip redundant patterns
• Improved binary response detection
• Added limit controls to the knowledge base items to prevent performance degradation of excessive amounts of items
• Default user agent string is set to the one used in IE8
• Improved the importers, manual proxy and Form Authentication Configuration wizard to support JSON, XML and multipart/form-data requests
• Improved multipart/form-data request parsing
• Knowledge base user interface improved
• Improved form value pattern for URL inputs
• Add vulnerability database version information to related vulnerability templates
• Configure Form Authentication wizard clears persistent cookies when started

Bug Fixes in Netsparker

Apart from the above noticeable changes that will definitely allow you to be more productive and detect more vulnerabilities in your modern web applications, Netsparker version 3.1 contains a lot more changes and bug fixes which are listed in the Netsparker Web Application Security Scanner change log.

Download 15 Day Trial of Netsparker

Netsparker makes web application security an easy task! It only takes a couple of minutes to launch a security scan with Netsparker and identify vulnerabilities and security issues in your web applications. Download the 15 Day trial edition of Netsparker today and see for yourself!

Upgrading your Netsparker

If you are already using Netsparker Web Application Security Scanner, a pop up window with the upgrade details will pop up the next time you run Netsparker. Alternatively you can always click on Check for Updates from the Help drop down menu to force manual updates as well.

If you have any queries, get in touch with our awesome support team by sending us an email on support@netsparker.com

We are very excited to announce the new version 3.1 of Netsparker Web Application Security Scanner. After our major version 3 update, it took us 5 months to release 3.1, however it was worth the wait as  the new version of Netsparker raises the web application security bar to new levels!

Overview of Netsparker 3.1 Features

Full HTML5 Support

One of the most important features in Netsparker 3.1 is the new HTML5 engine. With this new dedicated engine Netsparker users can automatically crawl modern HTML5 web applications much better and identify more vulnerabilities in them. Crawling takes full advantage of new HTML5 specifications and crawls the application with more coverage.

New Web 2.0 Security Checks

Netsparker 3.1 is also able to parse and attack JSON and XML payloads in HTTP request to identify a new type of vulnerabilities in them. These type of HTTP requests are typically used in modern and dynamic web 2.0 applications.

More Detailed Analysis of Target Web Application

The new version of Netsparker will also report much more valuable information about the target web application such as frames with external URL’s, Adobe Flash movies, Java Applets, ActiveX objects, comments in HTML, JavaScript and CSS and much more. Such information is typically sought after by penetration security testers and web application security experts alike since it helps them get a better understanding of the web application they are testing.

Automatic CSRF Vulnerability Detection

We added a new Cross-site Request Forgery engine that’ll help you to spot and address all kinds of variations of this nasty vulnerability.

Improved Logging and Integration with Third Party Tools

We also improved the logging in Netsparker, add added new compatibility with third party tools. In version 3.1 you can configure Netsparker to log all the HTTP requests and responses sent and received during a web security scan. These logs can be exported to Fiddler to further analyse the scan results and the web application behaviour.

Further Details of What is New and Improved in Netsparker 3.1

But this is not everything, in 5 months our team did much more! We worked hard to improve the existing security checks, we improved the accuracy of our scan results and we also ensured that Netsparker kept on delivering false positive free web application security scans. For more information about what is new in version 3.1 refer to the post Netsparker 3.1 Features and Improvements Highlights.

Download 15 Day Trial of Netsparker

Netsparker makes web application security an easy task! It only takes a couple of minutes to launch a security scan with Netsparker and identify vulnerabilities and security in your web applications that could leave you exposed. Download the 15 Day trial edition of Netsparker today and see it for yourself!

Netsparker Version 3.1 Press Release

The Netsparker Web Application Security Scanner Version 3.1 press release is available here: Netsparker Web Application Security Scanner Fully Supports HTML5.

Upgrading your Netsparker Web Application Security Scanner

If you are already using Netsparker Web Application Security Scanner, a pop up window with the upgrade details will pop up the next time you run Netsparker. Alternatively you can always click on Check for Updates from the Help drop down menu to force manual updates as well.

If you have problems with the upgrade or product related queries, get in touch with our awesome support team by sending us an email on support@netsparker.com

A new update of Netsparker Web Application Security Scanner is available for download. In this new version 3.1.4 we included small improvements to the user interface and also improvements the mechanics of the security scanner, such as improved the validation of the Custom 404 Error Page RegEx, improved the Cross-Site Scripting vulnerability template etc.

We have improved the Netsparker Scan Policy Editor dialog for better usability in this release. You no longer need to open the settings dialog to edit settings of a policy, the settings are just right below to the selected policy. This will save you a few clicks while you are customizing your policies.

Refer to the below list for more detailed information about what was improved and fixed in this new version of Netsparker.

Netsparker Improvements in this Build

• Added new keywords to the default list of sensitive keyword in Comments
• Improved Scan Policy Editor dialog to default to unique policy names when a new policy is created or cloned
• Improved Custom 404 RegEx validation to prevent empty patterns
• Improved HTML5 engine to ignore non-HTTP protocols on iframe sources
• Improved Configure Form Authentication wizard to use the selected Scan Policy settings (Custom headers, proxy, user-agent, etc.) on Start a New Scan dialog
• Improved Cross-site Scripting vulnerability template

Bug Fixes

• Fixed wrong PDF scaling issue which causes fonts to be rendered very small for report templates
• Fixed DOM Parser InvalidCastException crashes while trying to cast option tags on some cases
• Fixed form "action" value reported wrong on vulnerability details
• Fixed Internal Proxy port value setting upper bound to 65535
• Fixed incorrect attack possibility calculation for XSS confirmation requests
• Fixed dialog sizes on various screen resolutions and DPIs
• Fixed some issues in XSS detecting within script blocks
• Fixed XML attacks where reserved "xmlns" attribute values were being modified
• Fixed a DOM Parser issue on HTML pages with nested form tags

Upgrading your Netsparker Web Application Security Scanner

If you are already using Netsparker Web Application Security Scanner, a pop up window with the upgrade details will pop up the next time you run Netsparker. Alternatively you can always click on Check for Updates from the Help drop down menu to force manual updates as well.

If you have problems with the upgrade or product related queries, get in touch with our awesome support team by sending us an email on support@netsparker.com

Today we released a new updated version of our free SQL Injection Scanner Netsparker Community Edition.

This update of Netsparker CE includes all the latest security checks released in Netsparker Web Application Security Scanner 3.1, so if you are wondering if your websites and web applications are vulnerable to malicious hacker attacks, download Netsparker CE and find out all vulnerabilities and close them before malicious hackers can exploit them.

With Netsparker Community Edition you will get an overview of the security state of your websites and web applications within a couple of minutes. Netsparker CE will scan your website and report all identified vulnerabilities, but will only report vulnerability details for SQL Injections.

Should Netsparker CE report other vulnerabilities, then it is time for you to get the full version of Netsparker and get all the vulnerability details you need to close down those security holes.

Download Netsparker Community Edition today and do not hesitate to get in touch with us should you have any queries.

The new update of Netsparker Web Application Security Scanner includes vulnerability classification for PCI DSS version 3.0, which was released just a couple of weeks ago.

Netsparker 3.1.7.0 also has an updated PCI DSS compliance report template that enables Netsparker users to generate PCI DSS compliance report and see which of the vulnerabilities Netsparker detected should be fixed to ensure their web applications are PCI compliant.

This latest update also includes an updated vulnerability database which includes new security checks for Apache web server, Python, NginX web server, MySQL database server, WordPress and Drupal CMS solutions, PHP and others.

Upgrading Netsparker Web Application Security Scanner

If you are already using Netsparker Web Application Security Scanner, a pop up window with the upgrade details will pop up the next time you run Netsparker. Alternatively you can always click on Check for Updates from the Help drop down menu to force manual updates as well.

If you have problems with the upgrade or product related queries, get in touch with our awesome support team by sending us an email on support@netsparker.com

When it comes to compliance, especially as it relates to web application security, the Payment Card Industry Data Security Standard (PCI DSS) is usually the main topic of discussion. Unlike the more vague government regulations such as the Gramm-Leach-Bliley Act (GLBA) Safeguards Rule and the Health Insurance Portability and Accountability Act (HIPAA) Security Rule, PCI DSS is very prescriptive.

PCI DSS and its sister regulation PA-DSS provide guidance on exactly what’s expected in terms of how web applications and related systems that process or store cardholder data must be secured. This is beneficial to the entire payment card industry because it helps ensure that everyone is on the same page and leaves little room for interpretation.

PCI DSS 3 for January 2014

Well, the next chapter in PCI compliance has just begun. Over three years after PCI DSS version 2.0 was released, the PCI Security Standards Council (SSC) has published its latest updates in PCI DSS version 3.0. These new standards take effect on January 1, 2014. But don’t be alarmed. The version 2.0 standards will remain in effect through 2014. Therefore banks, merchants, processors and other affected entities will have until 2015 to align themselves with PCI version 3.0’s requirements.

PCI DSS 3.0 - Impact on Your Business

So, how does the new PCI DSS 3.0 standard impact you and your business in terms of web application security? The essence of PCI DSS remains the same:

1) build and maintain a secure network and systems
2) protected cardholder data
3) maintain a vulnerability management program
4) implement strong access control measures
5) regularly monitor and test networks
6) maintain an information security policy.

What’s different about PCI DSS 3.0 is the guidance around integrating its requirements with business processes and enhancing security assessments to ensure all areas are properly addressed. In fact, a new section in PCI DSS 3.0 titled Best Practices for Implementing PCI DSS into Business-as-Usual Processes states the obvious yet it’s something that’s often taken for granted:

“PCI DSS should be implemented into business-as-usual (BAU) activities as part of an entity’s overall security strategy.”

The business-as-usual integration section also highlights the importance of proactive monitoring, timely response, managing changes, and periodic reviews to ensure PCI DSS’s requirements are actually made part of everyday business operations. Again, they’re stating the obvious. However, if you look at web security breaches, the underlying causes are, in most cases, due to a failure in one or more of those areas of security management.

The following are the new requirements in PCI DSS 3.0 that the PCI SSC has made note of:

• Req. 5.1.2 - evaluate evolving malware threats for any systems not considered to be commonly affected
• Req. 8.2.3 - combine minimum password complexity and strength requirements into one, and increase flexibility for alternatives
• Req. 8.5.1 - for service providers with remote access to customer premises, use unique authentication credentials for each customer
• Req. 8.6 - where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.) these must be linked to an individual account and ensure only the intended user can gain access
• Req. 9.3 - control physical access to sensitive areas for onsite personnel, including a process to authorize access, and revoke access immediately upon termination
• Req. 9.9 - protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution
• Req. 11.3 and 11.3.4 - implement a methodology for penetration testing; if segmentation is used to isolate the cardholder data environment from other networks, perform penetration tests to verify that the segmentation methods are operational and effective
• Req. 11.5.1 - implement a process to respond to any alerts generated by the change-detection mechanism
• Req. 12.8.5 - maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity
• Req. 12.9 - for service providers, provide the written, agreement/acknowledgment to their customers as specified at requirement 12.8.2

Requirements 8.5.1, 9.9, 11.3, 11.3.4, and 12.9 above will be considered “best practices” to follow by the PCI SSC until July 1, 2015 when they will be enforced. The same goes for the web application-specific Requirement 6.5.10 (Broken authentication and session management).

Regardless of how you look at it, practically all of the changes in PCI DSS version 3.0 impact web application security in some way. Looking specifically at the one requirement that impacts web application security the most (Requirement 6: Develop and maintain secure systems and applications) you need to be aware of the following:

• There’s a greater emphasis on risk impact using industry best practices to consider what can actually happen if a vulnerability is exploited
• References to web-application firewall are now more generic (referred to as “automated technical solution”) to, presumably, incorporate additional technologies that can provide similar results
• At a minimum, testing for Requirement 6.6 and the much-changed Requirement 11.3 must include all vulnerabilities listed in Requirement 6.5 (i.e. XSS, CSRF, etc.) – security issues that are closely aligned with the OWASP Top 10 web application security risks
• The recommended Testing Procedures for Requirement 6.6 include an emphasis on reviewing processes and documentation, interviewing personnel, and analyzing system configuration settings to ensure proactive security controls are in place. Security testing outlined in Requirement 6.6 can still be performed by either third-party or internal organizations as long as they remain independent from developers.

All in all, PCI DSS version 3.0 is more of the same with a bit more business-centric substance and practical guidelines. If you have a strong information security program in place, you’re likely already addressing the new requirements. If not, there’s obviously some work in order. You have a year, but as we’re continually reminded working with web application security, time goes by quickly and things are harder to change than we think they’re going to be.

Are Your Web Applications Compliant with the New PCI DSS Version 3?

The time to get started with PCI DSS 3.0 compliance is now. Download it, scan your websites and web applications with Netsparker Web Application Security Scanner and generate PCI DSS version 3 compliance report to start to familiarize yourself with it. The deadline will be here before we know it.

“As a non-profit, we struggle to find and retain web application security specialists within our budget. Netsparker has allowed us to easily start the process of finding and patching web application vulnerabilities, as well as training our internal resources to spot and avoid these vulnerabilities" - Joshua Brower, New Tribes Mission, USA.

A Netsparker Case Study with New Tribes Mission, USA

New Tribes Mission USA needed to protect its web applications from malicious attacks by identifying web vulnerabilities, programming errors, and other security flaws in them. The non-profit organization chose to use Netsparker Web Application Security Scanner, a web application security market leader to continuously scan and protect their websites and web applications from the always increasing threat of malicious attacks.

Protecting Web Applications of a Non-Profit Organization

New Tribes Mission is an international organization that helps local churches train, coordinate and send missionaries to unreached people groups. To be able to do this, New Tribes Mission depends on a strong international workforce of translators, church planters, teachers, educators, nurses and several other professionals.

New Tribes Mission also runs a number of web applications such as employee portals to ensure that the thousands of its employees and volunteers can communicate with each other and work more efficiently. It also has an official website which is accessed by thousands every month.

Web application security has always been one of Josh Brower’s top priorities, because many of his non-technical colleagues frequently travel and access their custom built web applications from anywhere in the world. Therefore, if their custom built web applications are vulnerable, they will be easily attacked

Challenges of Securing Web Applications

Joshua Brower, New Tribes Mission Director of IT Operations and Security needed “a way to gain insight into the quality of security for a number of web applications that we run. Even though web application security scanners are not the silver bullet solution for our web security needs, it is a key layer of our Defense in Depth strategy”.

Although finding a web application security scanner sounds like a straightforward process for many, Brower faced a number of challenges:

• NTM was running custom web applications that were frequently updated with new functionality to meet changing business needs,The web applications were built using  different development frameworks, such as PHP and .NET and were also running on different web servers such as Apache and Microsoft IIS
• Working with a limited budget of a non-profit organization that cannot afford security specialists

After analysing the challenges, Brower’s requirement was very straightforward; an automated web application security scanner that can properly crawl and scan a variety of custom web applications built using different technologies, and that could verify identified vulnerabilities because the organization could not afford to retain web application security specialists.

Easy to Use and False Positive Free Web Application Security Scanner

After testing several different solutions, Brower chose Netsparker because it is an affordable solution and because “it has the ability to easily identify a lot of the low hanging vulnerabilities, confirm them, and generate a useful report to send to the pertinent personnel to deal with” said Brower.  “As a non-profit, we struggle to find and retain web application security specialists within our budget. Netsparker has allowed us to easily start the process of finding and patching web application vulnerabilities, as well as training our internal resources to spot and avoid these vulnerabilities—which means reducing our overall risk, and all within the boundaries of our non-profit budget.”

Netsparker Benefits

Detecting Exploitable Vulnerabilities

Today Brower uses Netsparker to scan more than 10 web applications at least once a week to ensure that there are no security holes that could be exploited by hackers. According to Brower, the return of investment on Netsparker is already very high because “Netsparker found an SQLi vulnerability in one of our business critical web applications that if exploited, would have resulted in total compromise of the application and its sensitive data”.
 
The web development team is also benefiting from Netsparker because it clearly explains where the vulnerabilities are and provides practical remediation solutions. Therefore, thanks to Netsparker, developers learn how to write secure code while they fix existing security issues.

World Class Product Support

Like any other software Netsparker can have bugs, and unfortunately Brower encountered a bug while using Netsparker. But identifying a bug in Netsparker was not a problem for Brower, as he explained “Support has been great.  We ran into a bug that was keeping us from using the product in a particular way, and within 24 hours, a new version was rolled out enabling us to continue using the product”.

About New Tribes Mission

New Tribes Mission is steadfast in its goal of reaching people who have no access to the Gospel. That was the vision for our ministry when we were founded in 1942, and it is our vision today.

About Netsparker Web Application Security Scanner

Netsparker Web Application Security Scanner is an industry leading automated web vulnerability scanner developed by Netsparker Ltd. Netsparker management and engineers have more than a decade of experience in the web application security industry that is reflected in their product. Netsparker is a very easy to use web application security scanner that automates most of the web application security scanning. An out of the box installation of Netsparker is able to scan a wide variety of web applications, therefore web security experts, penetration testers and QA engineers do not need to spend countless amount of hours tweaking and configuring the software. Netsparker is revolutionising web application security by being the only web application security scanner to automatically verify detected web vulnerabilities, thus reporting no false positives. Netsparker is used by world renowned companies such as Samsung, NASA, Skype, ING and Ernst & Young.

Lots of improvements in Permanent XSS, XSS and SQL Injection engines. We added experimental Second Order SQL Injection support as well.

There were some issues regarding to Proxy and Proxy Authentication, all those issues addressed as well.

There are many other improvements and some bug fixes, check out the details in the Netsparker v1.3.7.38 changelog.

• In March we released a new version : Netsparker 1.3.0.0 - increased performance, much better and effective Cross-site Scripting checks, user interface improvements, better proxy management and support and many other improvements. In April we released another version Netsparker 1.3.7.38. Adds better proxy management, experimental Second Order SQL Injection engine and many other improvements.
• We released our Free web application security scanner - Netsparker Community Edition, which was a great release. Currently there are thousands of Community Editions users and a new update for Netsparker Community Edition is ready as well. We are planning to release it soon.
• We have a new Help Desk and Forum to provide better support for Netsparker and Community Edition users. You can find Netsparker FAQ and some tips and tricks like Reading target websites from a text file.

Couple of Reviews

… Overall, I was quite impressed. The fact that it actually goes and tries the attacks with some dummy data, or even data that was pulled from context on the site is quite impressive. It even gives you tips or direct commands to run in order to fix some of the known issues. And where it doesn’t give specifics, it points you to the OWASP site for guidelines. I might have to look towards this again and will definitely keep a reference to it in my toolbox for future endeavours…

Gemini Security - Security Musings Blog, Netsparker

.. The community edition also found SQLi that AppScan failed to in a side by side test. ..

Cosine Security, Netsparker Community Edition Review

.. If we are to truly take any of this data seriously, then we must realize that Netsparker was the only web application security scanner that performed well in any sort of benchmarks I've seen yet. Crazier, it's the only one that's free that performs better than W3AF or Skipfish (and by a lot!). Netsparker Pro also carries one of the cheapest price tags I've seen or heard of. I would be interested to try it out and benchmark it more, especially after seeing the Community Edition. It's possible that Netsparker was released this way because they know that they have a superior product compared to the rest of the market ..

ntp, Web application scanners discussing in Sla.ckers

Couple of Twitter Mentions

@_ikki Netsparker's crawler rocks! I've just found a test script undetected by Acunetix and Skipfish.

@ToolsWatch Just finished a pentest (Netsparker was a great help). Thanks Netsparker Community Edition (i hijacked stream to spawn a shell :)

@abhaybhargav Netsparker is a great tool! It has some very unique features! Kudos!

We are going to release this update in couple of days, keep watching us, @netsparker.

A core principle of successful business ventures is planning ahead. It is something we have all learned the hard way and the adage is so true: if you fail to plan, you plan to fail. Like many aspects of business, planning your web application security testing in advance, can have enormous payoffs.

It may seem boring, but planning ahead can save you a lot of time and effort and even some embarrassment. Let’s take a look at the areas you need to be thinking about before you fire up your next web vulnerability scan. The basic building blocks for successful web security assessments are:

• Goals
• Objectives
• Strategy
• Methodology

Goals

Your goals are specific places where you want to end up. One of your goals might be to improve the security of your web applications so the business stops getting negative audit and compliance reports, or for some to stop having malicious intrusions and hack attacks.

Objectives

Your objectives are sub-goals that you must meet in order to achieve your longer-term goals. One of your objectives might to be to establish a periodic web application security testing plan for the next year, for example every month or every quarter or any time code changes are made to your business web applications.

Strategy

Next is your strategy which dictates how you are going to approach your web application security testing. Your strategy might include in-house or external testing resources, the tools you will use such as a web vulnerability scanner, and which websites and web applications you will test.

Methodology

Finally, your methodologies, which are sub-strategies, will outline the specific steps you will need to take to execute your web application security tests. An example of a methodology can be something as generic as the ethical hacking methodology of reconnaissance, enumeration, vulnerability detection, and vulnerability exploitation. A methodology could also be something more specific like unauthenticated vs. authenticated web vulnerability scanning.

Experience is always the best teacher so learn from others and be mindful that it is very easy to under-scope your web application security testing. Make sure you are looking at all the right web systems. You do not have to test everything at once but you do need to test everything that is critical to the business in the short-term. A longer-term goal would be to look at all web systems, eventually. One oversight in this area can have pretty serious business consequences such as a critical application that goes untested, or is assumed to be secure because a cloud provider or other third party says so, or a high priority vulnerability such as SQL injection that goes undetected.

If you get the right people on board such as developers, product managers, and higher-level IT and business executives, you will be able to develop a program around these areas of web application security testing. The important thing is to never go at it alone.

Perhaps more important than anything else is to not forget the basis of all your work: business risk. If you can understand the way the threats work to exploit vulnerabilities which, in turn, create business risks you will have a target to stay fixated on. That will help your business – and your web application security testing program – more than anything else.

Ultimately, the value of your web application security testing won’t reach its full potential unless you approach your work in terms of the business. Get – and keep – the right people on board, use the right tools, fine-tune your testing time after time, and you will create an environment where the proper web security risks are minimized and you get the credit you deserve for your efforts.

We are happy to announce version 3.2 of the false positive free Netsparker Web Application Security Scanner. The new version includes several new features, improvements that make web vulnerability scans more efficient and also a number of bug fixes. The main highlight of this version is the web services scanner; Netsparker users can now scan and identify vulnerabilities and security issues in web services automatically and easily with Netsparker.

Read this article for more information about all of the new features in Netsparker version 3.2.

Identify Vulnerabilities and Security Issues in SOAP Web Services

Netsparker 3.2 brings one of the long awaited features SOAP Web Services scanning to the table. Your much loved web vulnerability scanner Netsparker is now capable of crawling WSDL files and generate proper HTTP requests for the SOAP operations discovered to identify security issues and vulnerabilities in them. Scanning a web service with Netsparker is as easy as scanning a web application; just point Netsparker to your WSDL link and click the Start Scan button. The following screenshot shows a Boolean SQL Injection identified in a SOAP request on the target web service implementation.

Scanning a Web Application and Web Service Automatically in a Single Scan - Hybrid Scanning

Netsparker also supports what we call Hybrid Scanning of web applications and web services in a single scan. You can point Netsparker to root of your web site and if the crawler identifies a WSDL file, it will also start scanning the identified web service in the same security scan. One of the benefits of this scanning style is, if an attack to your web service endpoint surfaces on some other part of your web site, i.e. as a permanent XSS vulnerability, Netsparker will report it.

Import Offline WSDL Files to Start a Web Service Security Scan

The WSDL files do not necessarily need to be served on the target server for Netsparker to be able to scan a web service. If you have disabled WSDL generation on your production servers due to security concerns, you can import the WSDL file from your disk to Netsparker before starting the scan. Netsparker will parse the imported WSDL document and add the necessary SOAP requests to the crawler. WSDL files can be imported using the familiar interface of previous Fiddler, Paros, etc. importers on Start a New Scan dialog.

New Knowledge Base Node for Web Services

SOAP web services discovered during the security scan will also be reported in a new separate Knowledge Base node. You can see each operation of the discovered web services under Web Services (SOAP) node.

Web Services Standards Supported by Netsparker v3.2

At its current incarnation, Netsparker supports the following web service standards:

• WSDL 1.1
• SOAP 1.1
• SOAP 1.2
• HTTP GET & POST Binding

New Request and Response Viewers for New HTTP Request Formats

With the increase of different HTTP request formats that Netsparker supports on its recent versions, the need to representing these requests and response using better viewers has arisen. To resolve this issue, Netsparker 3.2 introduces the much improved request and response viewers which can render JSON and XML documents in tree views. The following screenshot shows a SOAP request and response using the XML viewers:

AJAX Knowledge Base Node

Netsparker now also reports any AJAX (XMLHttpRequest) requests under a new knowledge base node:

Complete Change Log for Netsparker 3.2

For a complete detailed changelog of what is new and improved in the latest version of Netsparker please visit the Netsparker Change Log.

We released a new update for Netsparker Community Edition. There is not much new features in Community Edition but this release addresses most common issues and includes several improvements. You can use “Help > Check Updates” or you can just download the latest version from Community Edition page.

We will be exhibiting in OWASP AppSec USA 2010 in California. We'll have limited special Netsparker Professional offers and live Netsparker demos during the conference. Don't forget to stop by and say "Hello"!

Here at Netsparker we are obsessed about the vulnerability detection rate of Netsparker Web Application Security Scanner, to ensure that all Netsparker users can uncover all possible web application vulnerabilities and fix them before malicious attackers have a chance of exploiting them.

As a matter of fact, over the years Netsparker has always ranked very high in several web vulnerability scanners benchmarks. To achieve such a good vulnerability detection rate, we are constantly scanning a number of test web applications with Netsparker, most of which are open source projects which are available to the publicand used by organizations as we speak.

Using the results from these tests, last year we published an infographic about the current state of web application security. From these statistics, one can come up with 2 conclusions:

First: No wonder web applications and websites are being hacked every day. Netsparker identified 181 unique vulnerabilities in 127 web applications.

Second: Encouraging for us, Netsparker is continuously identifying vulnerabilities in all sorts of web applications, independent of the framework / language they are built with.

Netsparker Advisories

When possible we release an advisory of the detected vulnerabilities. Last year we released 17 advisories of multiple critical web application vulnerabilities detected with Netsparker, most of which are Cross-site scripting, SQL Injections and Local File Inclusions. Fast forward to end of January this year and we already published the following 4 advisories:

• NS-14-004: Critical XSS Vulnerabilities in UseBB
• NS-14-003: Critical XSS Vulnerabilities in Flat Nuke
• NS-14-002: Critical XSS Vulnerabilities in Maian Weblog
• NS-14-001: Critical Blind SQL Injection Vulnerability in Pragyan CMS

Identify More Vulnerabilities with Netsparker

In just 3 years and 1 month, Netsparker published 47 advisories. In reality it identified much more vulnerabilities but it is not always possible to disclose the vulnerability details and publish an advisory. Are you sure your current web vulnerability scanner uncovers all vulnerabilities? Download Netsparker trial edition to see if it can uncover more web application vulnerabilities than your existing solutions.

Information
--------------------
Name :  XSS and Blind SQL Injection Vulnerabilities in ExponentCMS
Software :  ExponentCMS 2.0.5 and possibly below.
Vendor Homepage :  http://www.exponentcms.org
Vulnerability Type :  Cross-Site Scripting and SQL Injection
Severity :  Critical
Researcher :  Onur Yılmaz
Advisory Reference :  NS-12-006

Description
--------------------
Exponent is a website content management system (or CMS) that allows site owners to easily create and manage dynamic websites without necessarily directly coding web pages, or managing site navigation.

Details
--------------------
Exponent CMS is affected by XSS and SQL Injection vulnerabilities in version 2.0.5.

Example PoC urls are as follows :
http://example.com/index.php?section=(SELECT%201%20FROM%20(SELECT%20SLEEP(25))A)
http://example.com/index.php?action=showall_by_tags&tag=%27%22--%3E%3C/style%3E%3C/script%3E%3Cscript%3Ealert(1337)%3C/script%3E&controller=news&src=@random4e5433b85bb1f
http://example.com/index.php?controller=expTag&action=show&title=changes&src=%27%22--%3E%3C/style%3E%3C/script%3E%3Cscript%3Ealert(1337)%3C/script%3E

You can read the full article about Cross-Site Scripting and SQL Injection vulnerabilities from here :

• Cross-site Scripting
• SQL Injection

Solution
--------------------
The vendor fixed this vulnerability in the new version. Please see the references.

Advisory Timeline
--------------------
12/03/2012 - First contact: Sent the vulnerability details
20/03/2012 - Vulnerability Fixed in latest version
23/04/2012 - Vulnerability Released

Credits
--------------------
It has been discovered on testing of Netsparker, Web Application Security Scanner - /netsparker/.

References
--------------------

• Vendor Url / Patch : http://exponentcms.org/news/-happy-hyperbole-v2-0-6-is-in-full-bloom
• MSL Advisory Link : /blog/xss-and-blind-sql-injection-vulnerabilities-in-exponentcms/
• Netsparker Advisories : /netsparker-advisories/

About Netsparker
--------------------
Netsparker® can find and report security issues such as SQL Injection and Cross-site Scripting (XSS) in all web applications regardless of the platform and the technology they are built on. Netsparker's unique detection and exploitation techniques allows it to be dead accurate in reporting hence it's the first and the only False Positive Free web application security scanner.

{{advertisement}}

No matter where you are in your career, when testing for software vulnerabilities, there’s always room for improvement. Be it soft skills, tools, or all the little things in between, you can take your traditional black box scanning and turn it into a set of skills and deliverables that can make all the difference in the world.

Perhaps You Need Better Security Tools

The only proven way to find the most web vulnerabilities and security issues in web applications in the shortest period of time is to use a proven tool. For example by using an automated web vulnerability scanner, you can leverage the knowledge and resources of the vendor to find the maximum number of flaws unique to your specific web applications.

Web vulnerability scanners use hundreds, often thousands of iterations of web requests that test for both unknown and known web application vulnerabilities such as SQL Injection and Cross-site Scripting. The reporting available in web vulnerability scanners are also an extremely valuable asset, as you can share your high-level findings with management and technical details with developers.

You Might Need to Tweak Your Security Testing Methodology

If you see that you’re still not finding anything of significance, you may not be approaching your web security testing process the right way. There’s a proven “ethical hacking” methodology that encompasses:

1. Enumerating your web applications and web servers
2. Finding web application vulnerabilities and security issues
3. Demonstrating how those vulnerabilities can impact the web environment and business

This is how the bad guys work and it’s a great way to approach your web security assessments. That said it’s not just about the ethical hacking. If you’re going to find the significant security flaws, you need to ensure you’re testing your applications “with authentication” – as a trusted user – using multiple (perhaps all) user roles.  You also need to test your applications from different angles: from inside your network, outside your network, and both with and without network and host-based security controls, such as firewalls, WAF and IPS.

It’s virtually guaranteed you’ll find different vulnerabilities from these different perspectives. Plus, you’ll be several steps ahead of others (i.e. security admins, IT auditors, and even criminal hackers) because they often don’t test applications to this level of detail.

Or Maybe You Just Need More Experience

You can never get too much experience – especially as it relates to web application security, because everything is continually changing. The threats to web applications (criminal hackers, malware, malicious employees) are fairly static but the vulnerabilities are evolving constantly. That’s where having a good web vulnerability scanner comes in play, but it’s also dependent on you having a keen eye for what to look out for.

The best way to find more and better web application vulnerabilities and security flaws is to continue doing what you’re doing: testing, testing, testing. Keep in mind, however, it’s not just about getting “experience” – it’s critical that you’re getting good experience that you’re learning from and is continually helping to guide you in your approaches. As with software development and traditional QA, don’t be afraid to get hands-on training or even some knowledge transfer from someone who has been doing web security testing for a while. Attending information and web security-focused shows put on by RSA, Black Hat, and OWASP can be instrumental in advancing your web security testing skills.

As a QA professional, you’re in a perfect position to add even more value to the web security testing process. With a quality-focused mindset combined with the right tools and techniques that have been shown to uncover the important web security flaws, you can not only take your own QA testing to the next level but your peers, your business, and your customers will all benefit.

After pushing so many new features for Netsparker Professional users, it's time to update our Free Web Application Security Scanner - Netsparker Community Edition.

Netsparker CE now finds and confirms much more vulnerabilities. We also introduce registration in this version. This way we can give better support to Netsparker CE users and get better feedback from them.

Download Netsparker Community Edition v1.7.2.13

Happy New Year!

Advancements in web applications and other technology have changed the way we do business and access and share information. Many businesses have shifted most of their operations online so employees from remote offices and business partners from different countries can share sensitive data in real time and collaborate towards a common goal.

With the introduction of modern Web 2.0 and HTML5 web applications our demands as a customer have changed; we want to be able to access any data we want to twenty four seven. Such demands are also pushing businesses into making such data available online via web applications. A perfect example of this are the online banking systems and online shopping websites.

All of these advancements in web applications have also attracted malicious hackers and scammers, because like in any other industry there is money to be gained illegally. And this also lead to the birth of a new and young industry; Web Application Security.

This article explains the basics and myths of web application security and how businesses can improve the security of their websites and web applications and keep malicious hackers at bay.

Table of Contents

• We have a Secure Network Firewall
• We Scan our Servers and Network with a Network Security Scanner
• What about a Web Application Firewall?
• How Can I Secure my Web Applications?
• Web Vulnerability Scanners
• Choosing the Right Web Application Security Scanner
  • Commercial vs Free Vulnerability Scanner
• How to Test a Web Vulnerability Scanner
  • Ability to Identify Web Application Attack Surfaces
  • Easy to Use Web Vulnerability Scanner
  • Ability to Identify Web Application Vulnerabilities
  • Automating the Process
• When to use a Web Application Security Scanner
• A Complete guide to securing the Web Application Environment
  • Identifying Logical Vulnerabilities
  • Example of a Logical Vulnerability
• Securing the Web Server and Other Components
  • Switch Off Unnecessary Functionality
  • Limit and Secure Remote Access
  • Use Accounts with Limited Privileges
  • Permissions and Privileges
  • Segregate Development, Testing and Live Environments
  • Segregate Data
  • Always Install Security Patches
  • Monitor and Audit the Servers and Logs
  • Use Security Tools
• Stay Informed

We have a Secure Network Firewall

Most probably this is the most common web application security myths. Many think that the network firewall they have in place to secure their network will also protect the websites and web applications sitting behind it.

Network security differs from web application security. In network security perimeter defences such as firewalls are used to block the bad guys out and allow the good guys in. For example administrators can configure firewalls to allow specific IP addresses or users to access specific services and block the rest.

But perimeter network defences are not suitable to protect web applications from malicious attacks. Business websites and web applications have to be accessed by everyone, therefore administrators have to allow all incoming traffic on port 80 (HTTP) and 443 (HTPS) and hope that everyone plays by the rules.

Network firewalls cannot analyze web traffic sent to and from the web applications, therefore it can never block any malicious requests sent by someone trying to exploit a vulnerability such as an SQL injection or Cross-site Scripting.

We Scan our Servers and Network with a Network Security Scanner

Network security scanners are designed to identify insecure server and network device configurations and vulnerabilities and not web application vulnerabilities. For example if an FTP server allows anonymous users to write to the server, a network scanner will identify such problem as a security threat. Network security scanners can also be used to check if all of the scanned components, mainly servers and network servers such as FTP, DNS, SMTP etc are fully patched.

What about a Web Application Firewall?

A web application firewall, also known as WAF does analyse both HTTP and HTTPS web traffic, hence it can identify malicious hacker attacks. For example if the attacker is trying to exploit a number of known web application vulnerabilities in a website, it can block such connection thus stopping the attacker from successfully hacking the website. But such approach has a number of shortcomings:

Only Detects Known Vulnerabilities

A web application firewall can determine if a request is malicious or not by matching the request’s pattern to an already preconfigured pattern. Therefore most of the time web application firewall cannot protect you against new zero day vulnerability variants.

As Good as the Administrator

A web application firewall is a user configurable software or appliance, which means it depends on one of the weakest links in the web application security chain, the user. Therefore if not configured properly, the web application firewall will not fully protect the web application.

Does not Fix Security Holes in Web Applications

A web application security firewall does not fix and close the security holes in a web application, it only hides them from the attacker by blocking the requests trying to exploit them. Therefore if the web application firewall has a security issue and can be bypassed as seen in the next point, the web application vulnerability will also be exploited.

A WAF is Normal Application That Can Have Vulnerabilities

A web application firewall is a normal software application that can has its own vulnerabilities and security issues. Over time many security researchers identified several vulnerabilities in web application firewalls that allow hackers to gain access to the firewall’s admin console, switch off the firewall and even bypass the firewall.

Overall web application firewalls are an extra defence layer but are not a solution to the problem. In other words, if the budget permits it is of good practise to add a WAF after auditing a web application with a web vulnerability scanner. Additional layers of security should be always welcome!

Web application vulnerabilities should be treated as normal functionality bugs therefore should always be fixed, irrelevant if there is a firewall or any other type of defence mechanism in front of the application. In fact web application security testing should be part of the normal QA tests.

How Can I Secure my Web Applications?

To ensure that a web application is secure you have to identify all security issues and vulnerabilities within the web application itself before a malicious hacker identifies and exploits them. That is why it is very important that the web application vulnerabilities detection process is done throughout all of the SDLC stages, rather than once the web application is live.

There are several different ways how you can detect vulnerabilities in web applications. You can scan the web application with a black box scanner, do a manual source code audit, use an automated white box scanner to identify coding problems, or do a manual security audit and penetration test.

Which is the best method? There is no single bullet proof method that you can use to identify all vulnerabilities in a web application. Each of the methods mentioned above has its own pros and cons.

For example while an automated tool will discover almost all technical vulnerabilities, more than a seasoned penetration tester can, it cannot identify logical vulnerabilities. Logical vulnerabilities can only be identified with a manual audit. On the other hand, a manual audit is not efficient and can take a considerable amount of time and cost a fortune. With a manual audit there are also the risks of leaving unidentified vulnerabilities. White box testing will complicate the development procedures and can only be done by the developers who have access to the code.

If budget and time permits it is recommended to use a variety of all available tools and testing methodologies, but in reality no one has the time and budget to permit it. Therefore one has to choose the most cost effective solution that can realistically emulate a malicious hacker trying to hack a website; use a black box scanner, also known as web application security scanner or web vulnerability scanner. Of course an automated web application security scan should always be accompanied by a manual audit. Only by using both methodologies you can identify all types of vulnerabilities, i.e. logical and technical vulnerabilities.

Web Vulnerability Scanners

A black box web vulnerability scanner, also known as a web application security scanner is a software that can automatically scan websites and web applications and identify vulnerabilities and security issues within them. Web application security scanners have become really popular because they automate most of the vulnerability detection process and are typically very easy to use. For example to use a white box scanner one has to be a developer and needs access to the source code, while a black box scanner can be used by almost any member of the technical teams, such as QA team members, software testers, product and project managers etc.

Choosing the Right Web Vulnerability Scanner

There are several commercial and non commercial web vulnerbility scanners available on the internet and choosing the one that meets all your requirements is not an easy task. The best way to find out which one is the best scanner for you is to test them all. Below are some guidelines to help you plan your testing and identify the right web application security scanner.

Commercial vs Free Web Vulnerability Scanner

There are many factors which will affect your decision when choosing a web application security scanner. The first obvious one is; should I use a commercial software or use a free,  non-commercial solution? I recommend and always preferred commercial software. There are several reasons why, such as frequent updates of the software itself and the web security checks, ease of use, professional support and several others. For more information and detailed explanation of the advantages of using a commercial solution as opposed to a free one, refer to the article Should you pay for a web application security scanner?

How to Test a Web Vulnerability Scanner

Will you be scanning a custom web application built with .NET or a well known web application built in PHP, such as WordPress? Whichever web application you will be scanning, the security scanner you will be choosing should be able to crawl and scan your website. Although this sounds like the obvious, in practise it seems not.

For example many choose a web vulnerability scanner based on the results of a number of comparison reports released over a number of years, or based on what the web security evangelists say. Although such information can be of an indication of who are the major players, your purchasing decision should not be totally based on it.

Many others take another wrong testing approach when comparing web vulnerability scanners; they scan popular vulnerable web applications, such as DVWA, bWAPP or other applications from the OWASP’s Broken Web Applications Project. It is a wrong approach because unless the web applications you want to scan are identical (in terms of coding and technology) to these broken web applications, which I really doubt, you are just wasting your time. Such vulnerable web applications are built for educational purposes and are not in any way similar to a real live web application.

The best approach to identify the right web application security scanner is to launch several security scans using different scanners against a web application, or a number of web applications that your business uses. Note that it is recommended to launch web security scans against staging and testing web applications, unless you really know what you are doing.

Ability to Identify Web Application Attack Surfaces

During test scans verify which of the automated black box scanners has the best crawler; the component that is used to identify all entry points and attack surfaces in a web application prior to start attacking it. The crawler is most probably the most important component because a vulnerability cannot be detected unless the vulnerable entry point on a web application is identified by the crawler.

To identify the scanner which has the ability to identify all attack surfaces compare the list of pages, directories, files and input parameters each crawler identified and see which of them identified the most or ideally all parameters. If a particular scanner was unable to crawl the web application properly, it might also mean that it might need to be configured, which brings us to the next point; easy to use software.

Easy to Use Web Vulnerability Scanner

While some black box scanners can automatically crawl almost any type of website using an out of the box configuration, some others might need to be configured before launching a scan.

Because web application security is a niche industry, not all businesses will have web security specialists who are able to understand and configure a web application security scanner. Therefore go for an easy to use scanner that can automatically detect and adapt to most of the common scenarios, such as custom 404 error pages, anti-CSRF protection on website, URL rewrite rules etc.

Easy to use web application security scanners will have a better return of investment because you do not have to hire specialists, or train team members to use them.

Ability to Identify Web Application Vulnerabilities

The next factor used in comparing web application security scanner is which of the scanners can identify the most vulnerabilities, which of course are not false positives. I have seen vulnerability scanners identified hundreds of vulnerabilities on a website, but more than 70% of them were false positives.

If a scanner reports a lot of false positives, developers, QA people and security professionals will spend more time verifying the findings rather than focusing on remediations, hence try to avoid it. For more more information about false positives and their negative effect on web application security refer to the article The Problem of False Positives in Web Application Security and How to Tackle Them.

Automating Web Application Security

The more a web application security scanner can automate, the better it is. For example imagine a web application with 100 visible input fields, which by today’s standards is a small application. If a penetration tester had to manually test each input on the web application for all known variants of cross-site scripting (xss) vulnerabilities, he would need to launch around 800 different tests.

If each test takes around 2 minutes to complete, and if all works smoothly such test would take around 12 days should the penetration tester work 24 hours a day. And this is just about the visible parameters. And what about the under the hood parameters?

Typically there is much more going on in a web application hidden under the hood rather than what can be seen. Therefore it is difficult for a penetration tester to identify all attack surfaces of a web application in a fashionable time, while an automated web application security scanner can do the same test and identify all “invisible” parameters in around 2 or 3 hours.

But it is not just about time and money. When hiring a security professional for a web application penetration test, it will be limited to the professional’s knowledge, while on the other hand a typical commercial web application security scanner contains large numbers of security checks and variants backed by years of research and experience.

Therefore automation is another important feature to look for. By automating the security test will cost less and is done more efficiently. For more information about the advantages of automating web application vulnerability detection, refer to Why Web Vulnerability Testing Needs to be Automated.

When to use a Web Vulnerability Scanner

Web application security is something that should be catered for during every stage of the development and design of a web application. The earlier web application security is included in the project, the more secure the web application will be and the cheaper and easier it would be to fix identified issues at a later stage.

For example, an automated web application security scanner can be used throughout every stage of the software development lifecycle (SDLC). Even when the web application is in it’s early stages of development when it just has a couple of non visible inputs. Testing in the early stages of development is of utmost importance because if such inputs are the base of all other inputs, later on it would be very difficult if not impossible to secure them unless the whole web application is rewritten.

There are also several other advantages to using a vulnerability scanner throughout every stage of the SDLC. For example developers are automatically trained in writing more secure code because apart from just identifying vulnerabilities, most commercial scanners also provide a practical solution to how to fix the vulnerability. This helps developers understand and get to know more about web application security.

A Complete guide to securing the Web Application Environment

Scanning a web application with an automated web application security scanner will help you identify technical vulnerabilities and secure parts of the web application itself. But what about the logical vulnerabilities and all the other components that make up a web application environment?

Identifying Logical Vulnerabilities

Web application security scanners can only identify technical vulnerabilities, such as SQL Injection, Cross-Site Scripting, Remote Code execution etc. Therefore an automated web application security scan should always be accompanied by manual audit to identify logical vulnerabilities.

Logical vulnerabilities could also have a major impact on a business operations therefore it is very important to do a manual analysis of the web application by testing several combinations and ensure that the web application works as it was meant to be.

Example of a Logical Vulnerability

Imagine a shopping cart that has the price specified in the URL as per the example below:

/shoppingcart/index.php?price=250

What happens if the user changes the price from $250 to $30 in the URL? Will the user be able to proceed with the checkout and pay just $30 for an item that costs $250? If yes then that is a logical vulnerability that could seriously impact your business.

These types of vulnerabilities can never be identified by an automated tool because tools do not have the intelligence that allows them to determine the effect such a parameter could have on the operations of the business.

Securing the Web Server and Other Components

There are several other components in a web application farm that make the hosting and running of a web application possible. In a very basic environment at least there is the web server software (such as Apache or IIS), web server operating system (such as Windows or Linux), database server (such as MySQL or MS SQL) and a network based service that allows the administrators to update the website, such as FTP or SFTP.

All of these components that make up a web server also need to be secure because if any of them is broken into, the malicious attackers can still gain access to the web application and retrieve data from the database or tamper it. Therefore it is recommended that you to refer to the security guidelines and best practises documentation for the software you are using on your web server. Below are also some basic security guidelines which could be applied to any type of server and network based service:

Switch Off Unnecessary Functionality

The more functionality a network service or operating system has, the bigger the chances are of having an exploitable entry point. Therefore switch off and disable any functionality, services or daemons which are not used by your web application environment. For example typically a web server operating system has an SMTP service running. If you are not using such service switch it off and ensure that it is permanently disabled.

Limit and Secure Remote Access

Ideally administrators should be able to login to the web server locally. If not possible though ensure that any type of remote access traffic such as RDP and SSH is tunnelled and encrypted. It would also be beneficial if you can limit the remote access to a specific number of IP addresses, such as those of the office.

Use Accounts with Limited Privileges

Administrators do not typically like any type of restriction on their own accounts because sometimes limited privileges can be a little bit cumbersome to complete a specific task. Therefore if you work towards finding the right balance between security and practicality, you can have a secure web server while administrators can still do their job. For example an administrators can have different accounts to do different tasks; an account which is specifically used for backups, an account which is used for generic operations such as pruning of log files, an account which is used solely to change the configuration of services such as FTP, DNS, SMTP etc.

By using such approach you are limiting the damage that could be done if one of the administrator’s account is hijacked by a malicious attacker.

Permissions and Privileges

Complementing with user accounts, the same applies for every other type of service and application. For example most of the time the database user your web application is using to connect to the database only needs to read and write data to and from the database and does not need privileges to create or drop tables. But yet most of the time most administrators give an account all possible privileges because it “will always work”.

Another typical scenario for this type of problems are ftp users. FTP users which are used to update the files of a web application should only have access to those files and nothing else. Take the time to analyse every application, service and web application you are running and ensure the least possible privileges are given to the user, application and service.

Segregate Development, Testing and Live Environments

It is of utmost importance to always segregate live environments from development and testing environments. By mixing such environments you are inviting hackers into your web application.

When developing or troubleshooting a web application developers leave traces behind them that could help a malicious hacker to craft an attack against the web application. For example debug, which could be used to expose sensitive information about the environment of the web application is left enabled. Log files containing sensitive information about the database setup can be left on the website and could be accessed by malicious users.

Hence why it is important that any development and troubleshooting is done in a staging environment. Once the development and testing of a web application is finished, the administrator should apply the changes to the live environment and also ensure that any of the applied changes do not pose any security risks and  that no files, such as log files or source code files with sensitive technical comments are uploaded to the server.

Segregate Data

Similar to the above, the same applies to the data itself. Do not keep non related information in the same database, such as customers credit card numbers and website user activity. Store such data into different databases using different database users.

Apply the same segregation concept on the operating system and web application files. Ideally web application files, i.e. the directory which is published on the web server should be on a separate drive from the operating system and log files. By doing so you are not exposing operating system files to the malicious attacker in case he or she exploits a vulnerability on the web server.

Always Install Security Patches

Even though this is one of the most important steps in any type of security, unfortunately this is still the most overlooked task. It cannot be stressed enough how important it is to always use the latest and most recent version of a particular software you are using and to always apply the vendor’s security patches. By doing so you ensure that malicious hackers cannot find and exploit any known security vulnerability in the software you use.

Monitor and Audit the Servers and Logs

As the name implies, log files are used to keep a log of everything that is happening on the server and not simply to consume an infinite amount of hard disk space. From time to time every administrator should analyse the server log files. By doing so administrators can uncover a lot of information, such as suspicious behaviour on the server and therefore can better protect the web server better, or in case of an attack, can easily trace back what happened and what was exploited during the attack.

Use Security Tools

Apart from a web application security scanner you should also use a network security scanner and other relevant tools to scan the web server and ensure that all services running on the server are secure. Security tools should be included in every administrator’s toolbox.

Stay Informed

Last but not least, stay informed! Today you can find a lot of information for free on the internet from a number of web application security blogs and websites. By keeping yourself informed on what is happening in the web application security industry, or any other industry related to your job you are arming and educating yourself, so you’ll be able to better protect and secure web servers and web applications.