Quantcast
Channel: Invicti
Viewing all 1027 articles
Browse latest View live

Netsparker Community Edition, a Free SQL Injection Security Scanner Gets an Update

$
0
0

We announced Netsparker Community Edition in early 2010. Security community loved it, however we weren’t sure about supporting it as we couldn’t figure out the consequences in the long term. You know, giving that much of Netsparker for free! Risky business.

Download Netsparker Community Edition now

Therefore we haven’t updated it so frequently as Netsparker Professional or Standard. From the time we released Netsparker Community Edition 1.7.2.13 till today, 6 significant updates were provided for commercial versions  but nothing new on the Community Edition.

After careful consideration we decided to keep Community Edition up to date with Professional and Standard editions of Netsparker. You might still see up to a month delay on Community Edition updates however it’ll get updated sooner or later.

I’m happy to announce the new version of Netsparker Community Edition. It has tons of improvements compared to 1.7.2.13 as we fixed pretty much all known issues.

No registration required, no strings attached! Use it for free; if you like, you can always upgrade to Netsparker Standard or Professional.

Download Netsparker Community Edition - Free Web Application Security Scanner

 


Netsparker Team Talks About Reinventing Their Freemium Model

$
0
0

There's been plenty of discussion among the startup community about the pros and cons of the Freemium business model. Some declare it to be a resounding success, whilst others see it as a dismal failure. And, somewhere between these two extremes lies the notion that it all depends on you.

From our perspective, Freemium has proved to be a trusty servant and a key element in our growth. It helped us to gain early traction when we launched our business two years ago. Since then it has underpinned our brand-building and SEO activities delivering a regular and a valuable stream of willing buyers to our order page as well. To date, the free Netsparker Community Edition has been downloaded over 175,000 times and, on any average month, we see an active user base of almost 15,000.

But despite our unreserved praise for what Freemium has given us, we are about to tear up the score card and start again. Why? Because we observed directly from our experiences that we can do even better.

Warning: This is a long post. It tells the story of how we got here and why we think we can re-work our Freemium formula for even greater success delivering much more value to our free users. Only time will tell whether we're killing the sacred cow. However, succeed or fail, we'll surely post an update and let the stats speak for themselves. If you're curious whether this experiment has a happy ending, then subscribe to our newsletter!

The Story So Far

Back in late 2009, our business was just like every other early-stage startup: an enthusiastic team with a big idea and no customers. Like any new entrant into an established market, Netsparker had a mountain to climb. And, when you're up against competition like IBM and HP, that can be an overwhelming challenge.

With a limited marketing budget and a product that nobody had ever heard of, we knew we needed to do something different to set ourselves apart. Freemium was not a new idea, even then, but it certainly wasn't commonplace in our niche, where the incumbent vendors were firmly rooted in all the old ways of the enterprise sales model.

So we decided to take a risk and see what we could achieve by giving our product away.

From the outset, our main concern was to decide on the restricted elements in the free edition.  We were committed to the principle that it should be genuinely useful in its own right; not simply an upsell device. But, aside from the warm feelings we got from fulfilling an obvious need in our community, our commercial instincts were also focused on leveraging that tiny subset of free users with bigger expectations (and budgets).

Don't Give Away the Store

Most Freemium strategies entail restricting features or limiting usage capacity, but we had an additional dimension to experiment with; coverage.

When Netsparker scans a website, it tests for lots of heuristic security checks for vulnerabilities. The user receives a detailed analysis of every detected vulnerability along with the background information about its implications and its remediation. It is this comprehensive detection and resolution capability that makes Netsparker so valuable in addition to the productivity features that make it easy and fun to use.

We recognized that we could safely remove many of the bells and whistles, but we hesitated before crippling the detection algorithms that were central to Netsparker's role. Apart from compromising our "genuinely useful" principle, this would mask some of Netsparker’s most impressive capabilities and effectively undersell our value proposition.

After much debate within our team, we reached the conclusion that we had no choice but to ship the free edition firing on all cylinders.

A Necessary Compromise

In addition to disabling a number of non-essential features, we carefully reviewed the coverage list and selected a subset of vulnerabilities that would be masked in the free edition.

This selection process was guided by the desire to strike the right balance between utility and temptation. If Netsparker reports one or more serious vulnerabilities in a typical scan, most users become convinced about its detection capabilities and are also intrigued by the possibility that their website has other (more serious) vulnerabilities that might be detected by the premium editions.

Furthermore we refined this approach by reporting some vulnerabilities conditionally. For instance, we chose to report SQL Injection - probably the most common and dangerous vulnerability - but only on the lower-end database platforms (MySQL and MS-SQL). Our reasoning was that, if you can afford Oracle, you can probably justify the investment in Netsparker Standard Edition.

And so it was that we launched the inaugural version of Netsparker Community Edition in April 2010, with a coverage policy that has remained almost untouched ever since.

Return to Core Principles

As we pondered and debated our plans for the latest version of Netsparker, we wondered whether there was a better way to restrict the free edition.

Despite the obvious need for a Freemium strategy that masks certain vulnerabilities, we never felt completely comfortable with its security implications for users. In the words of one of our skeptical team members, “it's like locking the doors of your house and leaving the windows open”.

However, we realized that we had acquired a mass of data since we took our very first shots in the dark and that we could use this to create a better Community Edition; one that delivers more to its users and, at the same time, returns more to its creators.

From our own extensive studies and publicly available data such as Whitehat Website Security Statistics Report, we know that the vast majority of websites has at least one detectable vulnerability and a worrying number (upwards of 30%) have one or more critical security flaws – the kind that could wipe out a business. Thus we set about crunching the numbers, aiming to devise a new and a bolder coverage strategy.

As a result, the latest version of Netsparker Community Edition takes a completely new approach to the coverage that is expected to come as a pleasant surprise for users. It will also, hopefully, bring us some karma points and maybe even some additional sales.

Whereas all previous Community Edition releases offered only a subset of the vulnerability coverage of the paid editions, v2.3 will test and report the complete range of vulnerabilities. Some vulnerabilities will have certain details masked, such as the information that helps users to pinpoint their source and resolve them, but all detected vulnerabilities will be identified.

Long story short, if Netsparker reports no vulnerabilities, then none is detected, not because it masked some of them, as it did previously. This is important to us, because we don't want any of our users to spend money on an upscale edition of Netsparker and discover that it brought them no additional benefits.

Aside from the ethical merits of our new approach, we also expect it to have a significant marketing benefit. Since we know that virtually every website has at least one vulnerability and since Netsparker now reports them all, every Community Edition scan is a potential upsell opportunity.

We are anxious to observe the real impacts of this reasoning in the coming months. We’ll post an update as soon as the numbers are conclusive, so be sure to subscribe.

 

Netsparker 2.4.2.0 Supports Custom HTTP Headers in Automated Web Application Security Scans

$
0
0

If you used Chrome browser you know how great its update system is, just like you we love that feature of Chrome, so we implemented a similar seamless update system for Netsparker Web Application Security Scanner. It’ll update what’s only necessary and install in the background without requiring any extra steps or clicks. This is an important step for the future of Netsparker, as this will allow us to push much more features to you without waiting too long.

New Error Reporting and Help Desk Integration

This is one of those things we hope you’ll never, ever see!

We provide really extensive and quick support and proud of it. To make it even better if Netsparker crashes on you now you see an interface which will attempt to look for a known solution and show you the solutions for that problem. If there are no known issues or the problem hasn’t solved for you after trying you’ll able to create a help desk ticket from Netsparker and our support team will get back to you swiftly.

Custom HTTP Headers

For those special applications or any interesting setup now you can add custom HTTP Headers to all requests done by Netsparker.

New Security Checks

  • Possible Windows Username Disclosure vulnerability detection
  • LigHTTPD Directory Listing vulnerability detection
  • Nginx Directory Listing vulnerability detection
  • LiteSpeed Directory Listing vulnerability detection
  • Generic Email Address Disclosure vulnerability detection (Now Generic Email Address Disclosure and Email Address Disclosure reported separately)
  • LigHTTPD Version Disclosure vulnerability detection
  • Nginx Version Disclosure vulnerability detection
  • SharePoint Version Disclosure Detection
  • IIS 8 Default Page Detection
  • Struts2 Development Mode Enabled Detection

Security Check Improvements

  • Highlighting added for Out of Date vulnerabilities
  • A new ASP.NET XSS bypass
  • New LFI (Local File Inclusion) checks
  • Improved Apache version matching
  • Improved HTTP Header Injection engine
  • Improved Unix Internal Path Leakage detection
  • Improved vulnerability reports by fixing typos and improving the language used
  • Improved Social Security Number vulnerability detection
  • Improved XSS engine where an extra slash character was causing problems

Other Fixes & Improvements

  • Lots of new default form values added. This can be configured from “Settings > Form Values”
  • Decreased the amount of request done by stripping unnecessary URLs produced by Netsparker attacks
  • Improved binary detection
  • Improved Detailed Scan Report where it handles long non-breaking lines better
  • Improved Configure Form Authentication wizard to exclude monitoring unrelated requests
  • Improved extensibility API where headers now can be accessed via keys (header names)
  • Improved Target URL text box in Start a New Scan dialog where it no more auto fills the email address in the clipboard
  • Improved Detailed Scan Report code by slightly refactoring
  • Improved User Manual documentation
  • Improved splash screen which no more steals focus
  • Fixed some external links in XSS documentation
  • Fixed a resource deployment bug which causes file access violations
  • Fixed a bug in JavaScript / AJAX Parser
  • Fixed Unicode non-breaking space character issue for report templates
  • Fixed intermittent TypeLoadException for ExtensibilityDelegateCollection bug
  • Fixed visual glitches seen on higher DPI settings
  • Fixed the incorrect behavior when Microsoft .NET Framework 4 Client profile is used. Netsparker will only launch on Extended edition
  • Fixed InvalidOperationException error while trying to generate a Crawled URL List report during a scan
  • Fixed "Token substitution failed." error when an HTTP request fails
  • Fixed a bug which crashes Netsparker when “Trebuchet MS Regular” style font is not installed
  • Fixed "InvalidOperationException: Stack empty." bug in Crawler
  • Fixed .NET URI decode bug occurs while unescaping path dots and slashes
  • Fixed a bug where the ViewState is highlighted wrong on the GUI
  • Fixed a bug where starting a new scan crashes Netsparker with NullReferenceException
  • Fixed a bug where Form Values settings grid was reporting an unexpected empty field error
  • Fixed a bug where regular 404 pages are added to Sitemap when Custom 404 is disabled
  • Fixed URI parsing bug caused by mailto: links
  • Fixed a bug which happens when you try to open Start a New Scan dialog while Netsparker is loading
  • Fixed Anti-CSRF token extraction when multiple forms exist in a page
  • Fixed a bug where false-positive "Redirect Body Too Large" vulnerability is reported when url location is double-encoded in body
  • Fixed an issue where "JavaScript / AJAX Parser" was making requests to image resources

Update

If you have a valid Netsparker Professional or Standard license then all you need to do is click "Help > Check for Updates" to update to Netsparker 2.4.2.0. Your next update will be delivered by the new seamless update system.

 

Netsparker 2.4.5.0 Supports Windows 8 Operating System

$
0
0

If you are not living under a rock, you should have noticed that Microsoft has released the latest version of Windows by the end of October this year. Terribly ashamed to admit, due to a third party component incompatibility, Netsparker couldn’t run on Windows 8. Finally, we have fixed the issue and are proud to announce that latest release of Netsparker running on Windows 8.

Win8-Logo

Vulnerability Database Update

This release also contains updates to our vulnerability database. We have added vulnerability checks to detect more version vulnerabilities for the latest versions of PHP, Apache, MSSQL, MySQL, Tomcat and OpenSSL.

Other Fixes

  • Fixed a typo in “Scanned URLs List (CSV)” report.
  • Fixed tab key order on “Schedule a Scan” dialog.

Update

If you have a valid Netsparker Professional or Standard license then all you need to do is click "Help > Check for Updates" to update to Netsparker 2.4.5.0.

 

20 Percent Time Allocated to Non Work Related Projects - A New Netsparker Company Policy

$
0
0

For the last few months we have been experimenting a slightly modified version of Google’s “20 percent time” policy here at Netsparker and it seems to be working quite well.

“When you're hired at Google, you only have to do the job you were hired for 80% of the time. The other 20% of the time, you can work on whatever you like – provided it advances Google in some way. At least, that's the theory.”

Today I want to share our experience in this blog post.

Pet Projects

Google has pioneered this policy but later on, other companies like Apple (Blue Sky Project) and LinkedIn (InCubator Program) has adopted similar strategies to give their workers chance to work on projects that will somehow advance the company and also make the employees enjoy what they do. With the same spirit our employees are also free to work on what they are pleased to work on their 20 percent times. These pet projects could be:

  • A utility application not directly related with our business domain but will make our daily lives easier (see FogBugz Pivot)
  • A proof of concept work that would replace some inner machinery in Netsparker with a better design
  • A security research on a cool emerging technology that would eventually be integrated into Netsparker
  • A minor, low priority fix/enhancement to Netsparker which would never be implemented otherwise (We have these tasks marked with “Implement If Time” priority level and as you may have guessed, we do not implement much of those)
  • A blog post like this one

Members of the team should submit a brief description about what they are working on now or may just reveal a code-name of their project with no extra description to make other team members curios. You may form pairs/teams to work on a project too. We then schedule a day where we are presenting each other what we have done. We are currently experimenting a time frame like 2 months to do these presentations so every 2 months you should come up with something to present to the other team members. We are not expecting that every pet project should succeed with great results, we are seeing these as experiments and gathering the failure reasons is also valuable as succeeded projects.

My personal experience shows that the time I have spent for these kind of pet projects go beyond the 20% of my time at Netsparker and I find myself working on these projects in the evenings, at the weekends. You can guess how it feels better when you are working on a project that you enjoy as opposed to working on that damn dreaded finance report feature. Also having flexibility on feature set and technologies you use, you feel more free while you are developing.

Friday Techies

This is another thing that we spend our 20% time on, but this time collectively. On Fridays, we spare one hour or so to watch training videos on topics where we feel team members have lack of knowledge. During these sessions, we stop the video and having discussions on the topic and sharing ideas. This helps us to make sure all team members are on same page for that topic. If you are already familiar with this topic, you are getting more insight while you are trying to explain it to your peer and answering their questions. These sessions collectively increase the technical knowledge of the team and helps us to consume the training materials we have subscribed which otherwise would stay untouched.

For the time being, although it is too early to say, this strategy seems to be working for us and suggest you to give it a chance.

 

Netsparker 2.5 Integrates with Bug Tracking Tools and is Windows 8 Certified

$
0
0

Integration with Bug Tracking Tools and Send To Feature

Integrating Netsparker to other systems was one of the most requested features. We have tried to solve it by introducing this so called Send To feature. The idea is similar to the Send to file context menu item of Windows Explorer where you right click a file and send it to one of the predefined targets like Mail Recipient, Desktop, etc. Whereas in Netsparker, you can now right click a vulnerability on Sitemap or Issues panel and send it to a bug tracking system like FogBugz. With this version we are going to ship two Send To targets for popular bug/issue tracking systems FogBugz and JIRA. One of the best parts of this feature is that it is extensible and you are free to add your own target system with a bit of coding. There is an API for this feature and also we have a small tutorial to get you started.

SendToFeature

HTTP Strict Transport Security (HSTS) Test

HTTP Strict Transport Security (HSTS) is an opt-in security enhancement that is specified by a web application through the use of a special response header. Once a supported browser receives this header, that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS. If your web application uses HTTPS and doesn’t take advantage of HSTS (or misconfigured), Netsparker will report this. You can read more about HSTS on ScanToSecure blog.

Generate Exploit Feature

Sometimes it’s nice to have a proof of concept for issues like Cross-site Scripting. This new feature allows you to generate an HTML Proof of Concept file to exploit an XSS identified by Netsparker just by clicking the Generate Exploit button, so you don’t have to spend your valuable time to this.

GenerateExploitFeature

OWASP Top Ten Report

Ask and you shall receive! We now include one of the most requested report templates. You can see if your scan has vulnerabilities that are listed in OWASP Top Ten vulnerability list.

Windows 8 Certification

W8Comp

As of this version, Netsparker meets all the Windows 8 client app certification requirements and officially entitled to use Windows 8 Compatible logo.

Performance Improvements

Netsparker now keeps track of all responses and won’t run unnecessary checks more than once when the response is exactly same. This is enabled by default, can be disabled using Advanced Settings.

In certain websites this will significantly decrease the CPU load and will improve the performance of the scan.

New Security Checks

  • Shell Script Found detection
  • XHTML XSS Attack
  • Database Connection String Found vulnerability
  • Possible Administration Page Found Issue
  • UNC Server and Share Disclosure

Security Check Improvements

  • Vulnerability database with new version checks
  • Oracle admin check
  • SSN checks
  • ASP.NET detection
  • Elmah detection
  • Basic Authorization Required detection
  • Internal Path Leakage detection
  • File Upload Functionality detection
  • Generic E-Mail Address Disclosure detection

Other Improvements

  • Improved vulnerability templates by fixing typos and adding more reference/remedy content
  • Low quality icons on settings window
  • Settings windows by adding links to file/folder references on disk
  • API docs and User Manual
  • Settings user interface
  • Scan control by removing the Stop button and implementing a dirty tracking mechanism
  • Scan scheduling and added support for blank passwords
  • User agent selection behavior on HTTP Request settings screen
  • Reliability of session auto save
  • The naming consistency of vulnerabilities
  • Information, confirmation and error messages now uses Task Dialogs instead of regular Message Boxes

Bugs Fixed

  • A bug occurs on component dispose
  • The issue of momentarily black UI portions when minimized main window is restored
  • Long parameter value issue on Detailed Scan Report by trimming long values
  • A bug where Netsparker fails to open scan files (.nss) where extension contains upper-case letters
  • The broken text foldings on text editor for XSS vulnerabilities
  • Double encoded HTML output responses in Permanent XSS vulnerabilities
  • An issue with Burp importer where some files weren't recognized before
  • Wrong tab orders on various UI controls
  • A character encoding bug in SQL Injection Exploitation
  • A scan scheduling bug which occurs on non-English operating systems
  • Configure Authentication wizard recording step fixed and now it uses the configured user agent string on requests
  • JavaScript/AJAX parser fixed and now it uses the configured user agent string on requests
  • An issue which plays navigation sounds on systems where Explorer navigation sound is enabled
  • The incorrect CWE assignment of Invalid SSL Certificate vulnerability
  • An issue where retest was failing on first attempt

Update

If you have a valid Netsparker Professional or Standard license then all you need to do is click "Help > Check for Updates" to update to Netsparker 2.5.

 

Netsparker 2.5.3 Includes Enhanced Web Form Authentication Wizard

$
0
0

This is a minor update to Netsparker Standard/Professional editions which contains bug fixes and user interface enhancements for form authentication. We have fixed a critical bug where Netsparker was failing to detect logouts when form authentication is configured (especially for the scans that use keyword-based logout detection signature).

We have tried to increase the usability of the Configure Form Authentication wizard in this release. On the status bar of the wizard, we have placed a breadcrumb widget where it shows all the steps of the process and also highlights the current step you are at:

ConfigureAuthentication-Breadcrumb

On the first step of the wizard, we have included some mockup images that tries to illustrate the kind of web page URLs we are expecting the user to enter:

Step1

Second step of the wizard now contains a familiar user interface idiom on upper-right corner of the window, a camcorder recording animation. The user should now have a better feeling that any operation performed on this step is recorded:

Step2

And the third step (a.k.a. the playback phase) of the wizard has enhancements to keyword-based logout detection user interface. We have placed indicators right beneath the browser panes. While you are typing the logout keyword, it is matched to logged-in and logged-out views and the indicators update accordingly. You should make both of these indicators show green, as you know, green means go!

Step3

Security Check Improvements

  • Vulnerability database with new version checks

Bugs Fixed

  • Fixed a potential null reference exception on logout detection
  • Fixed a bug where session export confirmation isn't displayed while quitting application
  • Fixed a text parser issue happens when the page contains an option element without any value

Update

If you have a valid Netsparker Professional or Standard license then all you need to do is click "Help > Check for Updates" to update to Netsparker 2.5.3.

 

Are Hackers a Step Ahead? An Analysis using Web Application Vulnerabilities

$
0
0

If you have been involved in the IT industry you’ve definitely heard the myth that hackers are always a step ahead. It seems it is the truth because hack attacks are on the increase. Follow some of the popular IT news websites and you will read about hacked websites and stolen credit card numbers almost on a daily basis. Even if you are a home user, your friendly computer shop technician warned you to stay away from malware, viruses and hackers.

Businesses shifted most of their operations online and now they are depending on websites and web applications more than ever. Hackers know very well that most businesses do not invest in secure development and web application security and they take advantage of such fact and hack them.

I personally do not agree with the myth that hackers are always a step ahead. I think that the IT industry is way behind from where it should be. I am using the results of hundreds of web application security scans performed with Netsparker web application security scanner as an example to show that the IT industry can do much better in terms of security.

Security Scanning of Open Source Web Applications

As part of the quality assurance tests and to improve the web vulnerability detection rate of false positive free web application security scanner Netsparker, our engineers launch thousands of web application security scans throughout the year against test websites. Some of these websites are built using popular open source web applications, such as Joomla, Twiki, Blog Engine .NET and TomatoCart.

What Type of Web Applications were Scanned with Netsparker?

From the below numbers we can get a better overview of how many open source web applications were tested, with which web application framework they were built and what database backend they use.

  • 235 open source web applications scanned
  • 183 are built with PHP
  • 31 are built with ASP (Classic, .NET and MVC)
  • 21 are built from a variety of other web application frameworks
  • 183 use MySQL as database backend
  • 29 use Microsoft SQL Server as database backend
  • 23 use other database backend, such as PostgreSQL etc

Web Application Vulnerabilities in Open Source Web Applications

The results of the web application security scans of 235 open source web applications are quite shocking; 181 unique web vulnerability types were detected in 127 vulnerable open source web applications. Below are some statistics about the discovered web vulnerabilities:

  • 107 Reflective Cross-Site Scripting vulnerabilities
  • 17 Blind SQL Injection vulnerabilities
  • 13 Boolean SQL Injection vulnerabilities
  • 9 SQL Injection vulnerabilities
  • 6 Permanent Cross-Site Scripting vulnerabilities
  • 2 URI based XSS
  • Other discovered web vulnerabilities were a variety of command injection, command execution, HTTP header injection etc.

Different variants of SQL Injection and Cross-Site scripting vulnerabilities are still the most predominant web vulnerabilities. They sum up to 85% of the reported web vulnerabilities. When you consider that these 2 web vulnerability variants are considered as low hanging fruits vulnerabilities, and both of them were listed in the OWASP top 10 for the last decade, you would not expect to see them doing better than Lady Gaga does in the music charts!

The Aftermath: We are not Doing Enough to be One Step Ahead

Netsparker web application security scanner discovered both high and critical web vulnerabilities in around 54% of the tested open source web applications. Out of the 181 reported web application vulnerabilities, only 35 were fixed until today (23/04/2013). The other 146 zero day vulnerabilities in 127 open source web applications discovered by Netsparker are still not fixed. Therefore any website or blog running on such web application can be hacked since it has known security issues.

Web Application Security is a Must!

The whole point of this article is not to point fingers at someone and nor is to instigate some sort of an endless “open source vs closed source” debate. I am sure that if Netsparker engineers had the opportunity to scan closed source web applications with Netsparker web application security scanner they would still surprise us with the number of vulnerabilities Netsparker would detect.

The whole point is that everyone in the IT industry, from testers and developers to web masters and executives, still got a lot to learn about web application security if we want to be a step ahead of hackers. Non profit organizations such as OWASP, the PCI Security Council and security vendors such as Netsparker have been advocating web application security for years and hacking attacks are still on the rise. Unfortunately many web application development companies and communities from both sides of the globe, businesses and website owners are still not listening to what web application security experts are saying.

 

List of Scanned Applications and Vulnerabilities

List of all scanned applications and details of vulnerabilities if the relevant advisory is published.


What You Need to Know about the OWASP Top 10 2013

$
0
0

Do you use the Open Web Application Security Project (OWASP) Top 10 Project as part of your web security testing program? If not, now’s a great time to get on board. There’s a new version coming out for 2013 that can be an invaluable resource.

The OWASP Top 10 is a consensus of the most critical web application security-related risks. It provides a good framework on the issues to avoid when developing web applications as well as what to look for when testing for security weaknesses.
Currently in the release candidate stage, the OWASP Top 10 2013 has been tweaked to further enhance the web application security cause. Notable changes and improvements include:

  • Broadening of URL access control flaws to now include actual application functions
  • Expansion and merger of data-in-transit and data-at-rest flaws on both the server side and client side
  • Addition of a new category of flaws ‘Using Components with Known Vulnerabilities’ to include add-on and third-party software components (a common issue that’s often overlooked in development and security)
  • Re-prioritization of authentication/user session management and cross-site request forgery (CSRF)-related flaws

OWASP Top 10 2013

The new OWASP Top 10 of 2013 currently reads as follows:

  • Injection
  • Broken Authentication and Session Management
  • Cross-Site Scripting (XSS)
  • Insecure Direct Object References
  • Security Misconfiguration
  • Sensitive Data Exposure
  • Missing Function Level Access Control
  • Cross-Site Request Forgery (CSRF)
  • Using Components with Known Vulnerabilities
  • Unvalidated Redirects and Forwards

Use the OWASP Top 10 as a good resource for guidance around web application vulnerabilities. Just know that your mileage is going to vary when it comes to actual web security findings and what needs to be (or can be) done to fix the issues. Some security flaws you uncover pose real business risks. Some may exist but not matter in the grand scheme of what you’re doing. Other flaws appearing in the OWASP Top 10 will be non-existent. Your situation is unique and every application you look at is unique. Focus on what matters for your business.

The OWASP Top 10 is great for developers and QA professionals. It’s good for IT and information security. Most importantly, it’s good for business. The important thing is to leverage the OWASP Top 10 in the spirit of which it’s intended. It’s a free, yet invaluable, resource.

Go Beyond the OWASP Top 10 for a Complete Web Application Security Audit

Even though the OWASP Top 10 is an invaluable resource which one should follow when auditing a web application, you should not focus on finding web application vulnerabilities which are listed in this list only. The OWASP Top 10 list is to be used as a guideline and contains only the most critical vulnerabilities. There are many other web application vulnerabilities which could be exploited by hackers. Scan your websites and web applications with a web application security scanner such as Netsparker to uncover all other web application vulnerabilities your portals might have.

Businesses Need Automated Web Application Security Scanners to Detect Web Vulnerabilities

$
0
0

Some web security experts state that automated web application security scanners are not a good enough solution to secure your websites and web applications because they do not detect all web vulnerabilities.

As a matter of fact automated web application security scanners will find technical vulnerabilities such as SQL Injection and Cross-site scripting (XSS), but they cannot detect logical vulnerabilities. Having said that, on the contrary to what web security experts say, online businesses still need to invest and use web application security scanners to scan and secure their websites. Let’s take a look at some statistics and other web application security documentation to find out why.

OWASP Top 10

OWASP is a non profit organization which advocates web application security awareness. After analysing statistics of web application hacking attacks happening all over the world, OWASP publishes a list of the top 10 most critical web application security risks, i.e. the most commonly exploited web vulnerabilities.

The most common technical web application vulnerabilities detected by Netsparker, such as SQL Injection, Cross-site scripting, Injection Flaws, Invalidated Input etc have made it to all of the OWASP Top 10 lists which were released in 2004, 2007, 2010 and 2013.

Statistics of Hacked Websites

Each year, companies such as Verizon release an end of year report which includes statistics about the hacking incidents that happened throughout a particular year. From the 2013 Verizon data breach report we can see that 52% of the data breaches happened through web application hacking. Most of such attacks were successful because a technical vulnerability such as SQL injection was exploited.

Last year several other reports were released by well known brand names, such as Barclays, where they claim that more than 90% of the hacking incidents and data breaches are due to SQL Injection.

Current Web Hacking Attack Trends

Security firm Firehost just released its Q1 2013 web hacking attacks statistics where they detail the type and numbers of the most dangerous hacking attacks blocked by their firewalls. Cross-site scripting vulnerability attacks ranked first, amounting to 40% of all attacks. SQL Injection vulnerability attacks have had the second most significant increase in frequency when compared to last year.

Web Application Security Reality Check

One thing that we cannot deny is that low hanging fruit technical web vulnerabilities such as XSS and SQL Injection are still the most commonly exploited vulnerabilities. A web application security scanner such as Netsparker will detect these web application vulnerabilities in your websites and web applications and help you secure them.

Logical vulnerabilities should not be ignored, but as seen from the statistics these are rarely exploited. My recommendation is to first focus on the obvious; fixing of technical web application vulnerabilities. Hackers use automated tools to scan large number of websites every day and detect technical vulnerabilities to exploit them, so that is what they are going after first. Once the technical vulnerabilities have been addressed, then you can proceed and fix the rest.

 

The Problem of False Positives in Web Application Security and How to Tackle Them

$
0
0

A false positive is like a false alarm; your house alarm is triggered and there is no burglar. In web application security a false positive is when a web application security scanner indicates that your website is vulnerable to a web vulnerability such as SQL Injection, while in reality it is not.

Web security experts and penetration testers use automated tools such as web application security scanners to ease the job of a web application penetration testing. Web application security scanners are used to ensure that all of the web application’s input vectors are tested properly in a fashionable amount of time.

Unaffordable Web Application Security because of False Positives

Web application security scanners are known to report false positives, hence a web application penetration test consumes a considerable amount of time because the penetration testers has to go through all the reported vulnerabilities and verify them by trying to exploit them manually. Because of this, web application security is unaffordable for many businesses.

Unfortunately people working in the web application security industry are accepting the fact that web application security scanners tend to report false positives. So they are trying to learn to live with them rather than pushing security software vendors to develop better web vulnerability scanners. Apart from costs, false positives bring around new problems.

Ignoring the Real Web Application Vulnerabilities

By nature, we humans tend start ignoring false alarms rather quickly. Penetration testers are doing the same in a web application penetration test. For example if a web application security scanner detects 200 cross-site scripting vulnerabilities, if the first 10 variants are false positives the penetration tester assumes that all others are as well and ignores all the rest. By doing so, there chances that a real web application vulnerability is missed are quite high.

Lack of knowledge from Pen Testers means Scanners Report a lot of False Positives

The penetration test of your web applications depends on the knowledge of the penetration tester you hired rather than the capabilities of the web application security scanner. As we have already seen, since penetration testers do not trust web application security scanners they verify every reported web vulnerability the web scanner detects.

If the penetration tester, or the employee using the web security scanner is unable to exploit a particular web application vulnerability due to lack of knowledge or experience, such vulnerability is classified as false positive and will never be fixed.

Web Application Security Scanner vs Penetration Tester

Web application security scanners are not exactly the cheapest software you can buy, but neither are professional penetration testers. Business owners and Chief Security Officer might be wondering which is the best option to secure their web applications; invest in a web application security scanner that can be used by own employees or hire a professional penetration tester? And if we invests in a web application security scanner, do we have the right employee to verify its findings?

False Positive Free Web Application Security Scanner

The most productive and cost effective web application security solution is a false positive free web application security scanner which can be used by any of your technical employees. The benefits of having such a scanner is that web application penetration tests will consume much less time and your employees do not need to have years of hacking experience to verify the results.

Netsparker is the first web application security scanner on the market that is shipped with an exploitation engine which is automatically triggered when a web application vulnerability is detected. Exploitation is safe and read-only, so there is no chance of corrupting data or disrupting the website service because of it. Upon finding a vulnerability Netsparker automatically tries to exploit it and if it manages, it means that the vulnerability is definitely not a false positive. Netsparker will clearly report it to the user, so user can trust the results and doesn’t need to spend time to confirm it manually.

With this type of proactive and heuristic web application security scanning businesses do not need to hire expensive penetration testers to verify the findings of a web application security scan. Any developer taking care of your websites and web applications can quickly launch a web application security scan with Netsparker, analyse the findings and fix vulnerabilities.

 

Web Application Security Misconception; Are All Vulnerabilities Equally Dangerous?

$
0
0

You have just been promoted from a web application developer to a managerial role where you are responsible for the security of the company’s web applications. Happy about the new job, you launch a web application security scan against all websites and find out that all of them have vulnerabilities that need to be fixed.

Being pressed with time and on a limited budget you try to work out which web application vulnerabilities should be fixed and which should be left out, rather than asking your superiors for more time. Sounds familiar, doesn’t it?

And here is where the problems begin. Many people working in the web application security industry think that some technical vulnerabilities are not dangerous so not worth looking into and fixing them. This is a very common misconception; sql injection is more dangerous than a cross-site scripting vulnerability. In this article we will see why this web application security misconception is so common and what such misconception can lead to.

What is Cross-Site Scripting?

Cross-site scripting, also known as XSS, is a very common web application vulnerability. By exploiting a XSS vulnerability the attacker can inject malicious client-side scripts in a website which is later executed by the victims while browsing the website. There are different cross-site scripting variants, all of which can be used to craft different types of attacks. Read What is cross-site scripting web application vulnerability to learn more about this vulnerability.    

Why Many Think That XSS is not Dangerous?

Many web application developers think that cross-site scripting is not a dangerous web vulnerability because the victim is the user / visitor of the website rather than the actual web application, the web server or the data stored in the database.

For example if a forum user falls as a victim to a XSS vulnerability, the hacker would only gain access to the forum user’s profile, private messages and forum posts. Therefore we all think that by exploiting a cross-site scripting vulnerability a malicious user can never tamper the web application or steal sensitive data, such as customer details and credit card numbers. That is why in such cases, web application developers prefer to focus and fix web application vulnerabilities which when exploited allow hackers to gain access to server and compromise the website.

Cross-Site Scripting is as Dangerous as SQL Injection

What if the victim of the cross-site scripting attack is the forums administrator, as it happened in many cases? In this case, the attackers would gain admin privileges to the forums or any other vulnerable web application.

By combining a cross-site scripting attack with social engineering skills hackers can still penetrate networks, hack web servers and steal sensitive data. That is exactly what happened to the Apache Software Foundation in 2010; an attacker exploited a cross-site scripting vulnerability and worked his or her way up to gain root access to main apache.org shell servers. For more information about this attack, refer to the detailed Apache and JIRA attack documentation.

In the Apache incident mentioned above, the attacker exploited a non-persistent cross-site scripting vulnerability, hence the attacker needed social engineering skills to fully execute the attack. There were other cases in the past where attackers exploited a persistent cross-site scripting attack, which has a much bigger impact and one does not need to have social engineering skills to exploit it. Refer to the cross-site scripting technical documentation for more information about the different XSS variants. 

The Apache incident is not the only real life hacking incident where by exploiting a cross-site scripting vulnerability the attackers managed to do a lot of damage. There are several other ones we’ve heard of, but not all have been documented and it is not possible to list them all here.

Exploit a Cross-Site Scripting Vulnerability to Steal Money

It is a must to fix all web application vulnerabilities because if exploited, not only the company who owns the web application can sustain damage, but also its customers. And when as such happens, legal issues come into play.

Some people might not be bothered if a particular forum they used has been hacked, even if their forum account was affected. Mostly they reset their password, delete all the hacker’s activity and get back on with life.

But what if the e-banking web application your bank uses is vulnerable to a cross-site scripting attack? If it is, maybe a hacker won’t be able to take the system down but can easily hijack your e-banking session and transfer money out of your account.

All Reported Web Application Vulnerabilities should be Fixed

As we have just seen a cross-site scripting attack can be used to infiltrate the network of one of the most popular corporations in the world, or to hijack your e-banking session from where hackers can transfer money out of your account.

The aim of this article is not to scare people or show them what an attacker can be up to if he or she exploits a cross-site scripting vulnerability, but to raise awareness about web application security misconceptions.

As a web application developer or security expert you might think that a web application vulnerability on its own might not be enough for a hacker to break into a network or web server. Though it is enough to steal someone’s identity, money and destroy a life. It might also be used in conjunction with other attack methods to break into some of the most secure networks in the world. Seasoned malicious hackers are very smart and most of the time web application developers cannot imagine what they could be up to, so the approach everyone can take is to make sure that every reported web application vulnerability is looked into and fixed.

Check your Web Applications for All Types of Vulnerabilities

Download the 15 days trial version of Netsparker to scan all your websites and web applications for vulnerabilities such as XSS and SQL injection. Netsparker will automatically crawl your website and provide you with all the technical details when a vulnerability is detected within minutes. For more information about Netsparker Web Application Security Scanner you can visit the Netsparker product page.

 

South African Police Web Application for Whistleblowers Hacked via SQL Injection

$
0
0

On the 17th of May 2013 a group of hackers called DomainerAnon took responsibility for the hack of the South African Police Services (SAPS) website. DomainerAnon also claim an affiliation with the popular hacking group Anonymous.

In 2012 a member of the group had already tweeted about the fact that he believed the South African Police web applications and servers were vulnerable to an attack, like many other South African government websites. Back then he did not have any motives to attack them but after the Marikana massacre incident, where several striking miners where shot by the police, DomainerAnon retaliated and hacked the South African Police Services website.

South African Police Service Website Hack Details

The South African police website hosts an ASP web application called Crime Stop. The generic public can use Crime Stop to report criminal activity by submitting details through an online form. At the time of writing of this article, the ASP web application is still offline.

DomainerAnon exploited a simple SQL injection and retrieved sensitive data from the Oracle backend database. The database dump which included names, phone numbers, email addresses and ID numbers of people who submitted crime reports was uploaded online on a public website.

The 15,700 individuals, who used the website from 2005 and thought they had been providing information to the police anonymously and securely, now have their names known to everyone who managed to get his hands on the data dumps.

Included in the database dump were also the reports which range from rape cases to police brutality and beating. David Viaene posted a few censored examples on his blog. In the database dump there were also usernames and passwords of around 40 South African Police Service personnel.  Currently the database dump is no longer available to the public.

The South African police initially denied the hack attack until a reporter from a leading South African TV news channel called eNCA contacted people whose name and contact details were found in the database dump. The official eNCA report can be found here.

Safety Concerns

From the technical point of view, this hacking attack seems to be very typical one were sensitive information is disclosed to the public as part of a whistle blowing act. But in this case the whistle blowers themselves are the victims. What is worrying is that every reported person who stands accused of a crime can now find the information of who reported him or her. As a matter of fact several victims of this SAPS hack attack are very concerned about their safety.

Web Application Security Reality Check

Hacktivism, i.e. hacking to promote political believes is on the increase and people’s lives are being affected by it. Every website and web application owner should take responsibility and ensure that the data of everyone using his or her web applications is secure.

There is no magic formula one can use to secure web applications. Frequent scans with a web application security scanner will definitely save the day. In this particular case, if the South African Police Services used Netsparker to scan their web application they would have discovered the SQL injection vulnerability and avoided all this kerfuffle.

 

False Negatives in Web Application Security

$
0
0

As we have seen in a previous blog post, false positives in web application security have a long term bad affect on the security of your web applications and also on the procedures used for web application security. False negatives, i.e. web application vulnerabilities which are not detected by an automated vulnerability scanner can have the same long term bad effect, i.e. your web applications will have vulnerabilities that can be exploited by hackers.

What Causes False Negatives

The main reason why an automated web application security scanner does not detect a web vulnerability is because it did not crawl the vulnerable object. This type of automated scanner limitation raises again a number of questions, such as should automated web application security scanners be trusted and used in a web application penetration test?

Choosing the Right Web Application Security Scanner

The answer is yes, automated web application security scanners should be used, but one must do his homework properly when choosing an automated web application security scanner. One of the main features to look for when choosing a web application security scanner for your business is the crawler’s ability to crawl your web applications. Before the scanner starts attacking a web application, the crawler crawls all of the web application content to identify all the inputs and attack surfaces. If a single attack surface is not crawled, it will not be scanned for vulnerabilities and if there is a vulnerability, it won’t be reported.

Many of today’s modern web applications use custom 404 error pages, URL rewrite rules for search engine friendly URL’s and anti-CSRF mechanism to protect them from cross-site request forgery attacks. Although these features make a website more user friendly and secure, they typically hinder the crawler from identifying all attack surfaces.

The crawler of several automated web application security scanners can be configured and tweaked to crawl such web applications, but there is no guarantee it will identify all attack surfaces. Also configuring crawlers is very difficult and time consuming. Unless you are a seasoned penetration tester with years of experience, it is virtually impossible to understand what is happening under the hood of a web scanner. So unless your business affords an experienced penetration tester, you cannot use such scanners.

The Purpose of a Web Application Security Scanner

The whole point of investing in an automated web application security scanner is to ease the process of penetration testing and automate as much as possible, and not to spend countless hours tweaking it. A good web application security scanner should support at least 90 to 95 percent of web application technologies out of the box.  The best test to see if investing in an automated web application security scanner has a proper return of investment for your business is to simply try several different ones against a web application of your own and see if it crawls it properly without the need to tweak it.

Automatically Detect Web Vulnerabilities and Avoid False Negatives

Netsparker web application security scanner has a crawler that can crawl web applications built with any type of framework. You do not need to configure custom 404 error pages or URL rewrite rules. It heuristically detects them and auto configures itself to ease the job for you. The crawler of Netsparker also has a built-in AJAX and JavaScript engine which parses, executes and analyses these commonly used scripts in today’s web applications. Last but not least, Netsparker also supports anti-CSRF tokens to ensure that web applications that use such technologies can still be crawled automatically and all attack surfaces in a web application are identified. For more information about the Netsparker crawler refer to the Advanced Web Application Security Scanning section.

Download the 15 Days Trial of Netsparker

Download Netsparker Web Application Security Scanner to identify web vulnerabilities such as SQL injections and cross-site scripting on your business websites and web applications.

 

The Dangerous Complexity of Web Application Security

$
0
0

It’s an old saying but it’s been revived in information security circles lately: you have to find every security flaw but a malicious hacker only has to find one. It’s the harsh reality we face today it’s at the forefront of web application security.

Underscoring the exposure, the Verizon 2013 Data Breach Investigations Report found that 78% of the intrusions they analyzed were considered low difficulty, which means “low hanging fruit” type web application vulnerabilities were exploited. Web-based attack vectors are going down according to Verizon – making up only 22% of hacking actions analyzed. However, the 2013 Trustwave Global Security Report found that web applications were the most popular attack vector, making up nearly half of all investigations. Whichever side you believe, the old saying rings true with our websites and web applications today: any given web system has a lot of moving parts, is most likely rife with flaws, and all a criminal needs is one way in.

As much as we’d like to think that our web environments are relatively simple, they’re really not. Web environments are unique in that the attack surface is basically unlimited. From front-end perimeter security devices to the web server itself and on up to the database and application layer at the top, there’s a lot of exposure. There are also a lot of people involved in any given web system which further complicates matters. As much as management would like to think that their web environments contain nothing of value that hackers would want (an all too common assumption), they’re woefully misinformed.

This very moment, your web-based systems (both in-house and those hosted/managed by third parties) are a hotbed for manipulation and exploitation. All someone with ill intent needs is to stumble across one of the many common flaws that plague a large portion of production, development, and test environments such as:

  • Weak passwords that allow attackers to mimic legitimate users, and thus, not generating alerts
  • XSS and cross-site request forgery that can be manipulated to gain indirect access
  • SQL injection that provides a direct path to the sensitive data stored in backend databases.
  • Content management systems that have never been tested for security flaws because it’s assumed that others are taking care of them (more information on Are Hackers a step ahead? An analysis using web application vulnerabilities)
  • Missing patches that can facilitate remote command prompt access to servers
  • Firewall and server misconfigurations that can lead to denial of service attacks and other inadvertent exposure

A large number of these flaws are external-facing. Given that the Verizon report found that 92% of security incidents analyzed were perpetrated by outsiders, it’d behoove you to see what the world can see (and exploit) and make sure those web security holes are plugged. You also have to consider what else is happening in your internal web environment that goes undetected or unreported. There’s probably a lot going on right under our noses.

Interestingly, more and more IT and development businesses are admitting that their environments have become so complex that not a single person fully understands all the moving parts. There are certain web systems that no one even knows what they’re used for. The bigger problem is that no one is willing to step up and fully account for the what, where, how, and why of these systems.

One thing is certain, web complexity is growing, especially as codebases evolve and business processes mature. Even moving to the cloud introduces its own variables into the security equation. Web complexity correlates well with web risks. That’s your biggest enemy. The question is: what are you going to do about it?

 


Use Netsparker to Detect Ruby on Rails Vulnerabilities

$
0
0

On the 28th of January 2013, Ruby on Rails announced the release of versions 3.0.20 and 2.3.16 that addresses an extremely critical security in the framework itself. The vulnerability is a remote code execution and when exploited it allows an attacker to execute code on the remote web server.

In May 2013, automated bots started exploiting this known remote code execution in Ruby on Rails web framework. Even though it took almost four months for the vulnerability to surface in the wild, it seems that it is quite successful. The main reason to why it is so successful is because web servers administrators failed to upgrade their Ruby on Rails framework to the latest and most stable version.

Although most of successful attacks were not documented, in a particular case a malicious hacker who exploited this Ruby on Rails vulnerability managed to withdraw funds from Vircurex, an exchange platform for buying, selling and trading Bitcoins and other various alt-chains. Vircurex had posted on the Bitcoin forum reporting the attack.

How the Ruby on Rails Remote Code Execution Vulnerability is Exploited

It’s been reported that the Ruby on Rails remote code execution is exploited in the wild [*]. This particular worm works by adding a command to the crontab configuration file of the web server. When it gets executed, 3 files are downloaded and executed. Straight after another 2 files are downloaded and executed, one of which is a C source code file that is compiled using the compromised web server gcc compiler and executed.

Once the fifth and last malicious file is downloaded and executed, the process runs under the name of ‘- bash’, so when the web server administrator checks the process list, the malicious process looks like a normal bash process thus does not raise any suspicion.

While the malicious process is running, it connects to a pre programmed IRC bot from where it can receive commands to download and execute files and also to change the server it is connected to. Since there is no authentication control, anyone with basic IT skills can connect to the #rails IRC channel and hijack these infected bots.

Keep your Web Servers Secure with Netsparker

Although there are a lot of procedures one can follow to secure web servers or any other server, one of the most reliable ways is to always use the latest version of the software being used. The latest version is not just the most secure, but also the most stable and reliable.

Ensure that your web servers and web applications are secure by scanning them with Netsparker web application security scanner. Apart from detecting vulnerabilities in web applications, Netsparker also detects vulnerabilities in web server software and frameworks. Netsparker also checks if your Ruby on Rails installation is vulnerable to the above mentioned Ruby on Rails remote code execution vulnerability.

Download Netsparker to check if your Ruby on Rails web framework installation is vulnerable.

Reference about the Ruby on Rails Remote Code Execution Vulnerability

A discussion between administrators whom web servers fell victims of this attack discussing what they noticed so far on their web servers and in their web server log files can be found here.

* A detailed analysis of the attack by security consultant Jeff Jarmoc can be found here.

 

An XSS Vulnerability is Worth up to $10,000 According to Google

$
0
0

Last week Google increased the financial rewards for Google’s Web Vulnerability Program. What does this exactly means?

What is the Google Web Vulnerability Reward Program?

Internet giant Google pays up to $10,000 to whoever finds a web application vulnerability such as cross-site scripting and SQL injection in their web applications, such as Gmail, YouTube, Google Checkout, Google Wallet etc.

There are many other world renowned companies who are doing the same as Google, i.e. paying hackers that find web application vulnerabilities in their web applications. Some of these companies are Facebook, Paypal, Adobe and Mozilla.

Why Pay Hackers to find Web Application Vulnerabilities?

Web applications have become a vital part of our lives and online businesses depend on them. When you pay for a service online or check your bank accounts through an e-banking system, you are using web applications. Businesses use them to provide a service to their customers, to receive payments from their customers and also to store customer data and share it with their business partners and remote employees.

To be able to provide top quality services to their customers, businesses store sensitive data that has to be accessible via web applications. Typically such data consists of customer personal contact details, credit card numbers, social security numbers etc. To encourage more customers to use their service and gain trust, online businesses also have to ensure that their web applications are secure. As we have constantly seen in the news, businesses cannot afford to have a hacked web application because it leads to huge financial loss, tarnished reputation, and loss of customer trust. Sometimes a hack also leads to bankruptcy and business closure.

To make things worse web applications are becoming really complex and securing them is also becoming a very complex process. As we have seen in the blog post The dangerous complexity of web application security, businesses have to make sure they find all vulnerabilities and close them, while a malicious hacker only needs to find one to hack a web application.

Even though many businesses try their best to secure their web applications, malicious hackers seem to always manage to break into web applications and steal sensitive data. It didn’t take long though until online businesses such as Google learnt that by paying anyone who finds a vulnerability in their web application saves them money and most importantly of all, their business and service reputation.

Why Google Increased the Financial Rewards?

If like me you browse news websites on a daily basis, you will notice that every day some service or website is hacked and user information such as contact details and credit card numbers are leaked. Sometimes it gets even worse, like in the case of the South African Police website hack were details of thousands of whistleblowers were exposed. Such incidents became so common that most of them do not even make it to the news. And Google is no exception. With the wide range of web applications and services they host, I’m sure they have noticed an increase in web application attacks over the last couple of months. As a matter of fact, since Google launched the Web Vulnerability Reward Program in November 2010, Google already paid 250 individuals a whopping sum of $828,000.

In an effort to step up the game against malicious hacking, encourage more hackers to find web application vulnerabilities and ensure that their web applications and customers’ information are secure, Google increased the financial rewards. The financial reward for reporting a cross-site scripting vulnerability has more than doubled. Before Google used to pay up to $3,133.7 and now they are paying up to $7,500.

Is a Cross-site Scripting Vulnerability Really Dangerous?

The increase in the financial reward for reporting a cross-site scripting vulnerability is not a coincidence. Many people think that a cross-site scripting (XSS) vulnerability is not a dangerous vulnerability because by exploiting it one does not manage to retrieve data directly from the backend database as when exploiting an SQL Injection. This is just a misconception since actually one gets much more than that when exploiting a cross-site scripting vulnerability. Read our security blog post Web application security misconception – XSS is not dangerous for more information about this common misconception.

Detect Cross-site Scripting and SQL Injection Vulnerabilities in your Web Application

Like Google, is your business doing its best to find all vulnerabilities in web applications? There is no need to spend millions of dollars to ensure that your web applications and customers’ details are secure. All you need to do is scan your websites and web applications with Netsparker Web Application Security Scanner.

Netsparker is a false positive free web application security scanner that automatically detects security vulnerabilities such as cross-site scripting and SQL injection in your business websites and web applications, and it does not cost that much!

Download a trial copy of Netsparker web application security scanner today and detect vulnerabilities on your web applications that hackers can exploit.

 

OWASP Top 10 for 2013 Explained

$
0
0

OWASP, also known as Open Web Application Security Project just released the OWASP Top 10 for 2013. The OWASP Top 10 is a list of most common web application vulnerabilities and flaws found in today’s web applications. The list of security flaws is based on several datasets from different firms specializing in web application security and is aimed to help businesses who own websites and web applications simplify the process of securing web applications.

The OWASP Top 10 list has been released once every 3 years since 2004.. For more details about all the changes between OWASP Top 10 of 2010 and 2013 refer to What is New and What Changed in OWASP Top 10 2013. Below is the new list for 2013.

A1 - Injection

LDAP Query Injection, OS Command Injection and SQL Injection are all different type of injection flaws. An injection occurs when a malicious hacker takes advantage of insecure web application coding and manages to inject commands into forms such as a login form from where he or she then gain access to sensitive data stored in the web application backend database. Details about a real life example of an SQL injection attack and the dangerous repercussions it leaves can be found in the blog post Details of South African Whistleblowers Exposed via SQL Injection.

A2 - Broken Authentication and Session Management

Authentication in web applications is mostly used to grant or prohibit access to specific information to a particular user and session management is the management of already logged in users. Most common security risks related to authentication and session management are stealing of passwords or session tokens and impersonating legitimate users. Authentication and session management related flaws are typically identified in password reset functionality, by tampering cookies or session ID’s etc.

A3 - Cross-Site Scripting

A cross-site scripting (XSS) vulnerability allows a malicious hacker to inject malicious client-side script in a website or web application which is later executed by the victims. Typically, cross-site scripting attacks are used to bypass access controls and to impersonate legitimate users, such as the web application administrator. Some years ago a cross-site scripting vulnerability was used with other vulnerabilities to gain root access on the Apache Foundation servers. For more detailed information about this attack, refer to the blog post XSS to Root in Apache Jira Incident.

A4 - Insecure Direct Object References

Insecure direct object references is a flaw in the design of the web application where access to a sensitive object, such as a directory, a particular record or a database is not fully protected and the object is exposed by the application. A typical example would be when a customer accesses his bank accounts via e-banking and because of a flaw in the web application he is able to see someone else’s account as well.

A5 - Security Misconfiguration

Web application security is not just about secure web application coding. To ensure the security of a web application it is important to also secure the configuration of the web server, secure the operating system of the web server and ensure that it is always updated with the latest security patches. The same applies for the web frameworks being used, such as PHP, .NET etc and any other software being used on the web server.

A6 - Sensitive Data Exposure

Sensitive data stored in databases or any other object should be well protected. Credit card details, social security numbers and other sensitive customer details should be encrypted when stored in a database, even if they are not directly accessible via the web application. The same applies for sensitive data being transmitted to and from the web application, such as credentials or payment details. Such information should be transmitted over a secure and encrypted layer.

A7 - Missing Function Level Access Control

An attacker can exploit this type of security flaw by changing the URL in the browser when accessing a web application to try and access a function he does not have access to. If the web application fails to perform proper access control checks specifically for that particular object, the attacker is able to access the function he should not have access to.

A8 - Cross-site Request Forgery (CSRF)

A cross-site request forgery, also referred to as CSRF is widely popular with scammers and spammers because when exploited, the attacker can force a victim’s web browser to send a forged HTTP request to a vulnerable web application. Such forged HTTP request would typically contain logged in information such as the cookie details and other authentication related information which are later used to force the victim’s browser to send requests to the vulnerable web application while thinking that they are being sent to a legitimate web application.

A9 - Using Components with Known Vulnerabilities

It is quite surprising that this class of vulnerabilities is in 9th place, considering that most of today’s successful attacks happen because the attacker exploited a known vulnerability. The main reason malicious hackers are still able to exploit known vulnerabilities is because outdated software is still being used; administrators fail to update all of the software being used on web servers and by the web applications to the latest secure and most stable version on time.

A10 - Unvalidated Redirects and Forwards

Website visitors are frequently redirected and forwarded to different pages and even other third party websites depending on the visitor location, type of browser being used and several other factors. If the functions analysing such data does not properly validate the data, a malicious hackers can exploit such functions and use the legitimate website to redirect its visitors to a phishing website or any other type of malicious website.

Use the OWASP Top 10 in your Web Applications SDLC

There are several long term benefits your business will benefit from when you use and refer to the OWASP Top 10 list in your web application software development life cycle, such as ensuring that your web applications are not vulnerable and also train web developers to write secure code in future development projects.

How to Find OWASP Top 10 Vulnerabilities in Your Web Applications

You can find most of the web application security problems and vulnerabilities listed in the OWASP Top 10 by scanning your web applications with an automated web application security scanner at any stage of the development life cycle.

Netsparker, is a false positive free web application security scanner that automatically scans your website and identifies web application security vulnerabilities that could leave your sensitive data dangerously exposed to malicious hacking attack. Download the Trial Edition of Netsparker to check if your websites and web applications are vulnerable to any of the OWASP Top 10 vulnerabilities.

 

A Detailed Look into the New Features and Improvements of Netsparker Version 3.0

$
0
0

Finally Netsparker version 3.0 is soon to be released so stay tuned with us! We have listened to all of your feedback and did our best to add some new cool features. We improved the mechanics of the scanner, added new security checks and fixed a number of bugs. In this blog post we will go through what is new in Netsparker version 3.0. This version is a major update of both Netsparker Standard and Professional editions.

Scan Policy Editor

The Scan Policy Editor can be used to fine tune a scan by defining which web application security tests should be launched against a target web application, thus reducing scan duration time. Newly configured Scan Policies can be saved and used in future web application security scans. For more information on the new Scan Policy Editor and how to create custom Scan Policies refer to the Netsparker Scan Policy Editor post.

PCI Compliance Report

With Netsparker version 3 you can generate PCI compliance reports to check and confirm that your websites and web applications are PCI compliant. The PCI compliance report is mandatory for every website and web application that accepts any form of online payments. Failing to have PCI compliant online payment web systems may result in fines or having them closed down.

PCI Compliance scan report

Support for Multiple Exclude and Include Patterns

In previous version of Netsparker one could only specify a single value, which could be a regular expression to match a URL that should be excluded, or included in a web application security scan. In the new version of Netsparker it is possible to add as many matching patterns as you like, as can be seen from the screenshot below.

exclude or include patterns

Knowledge Base Node

Knowledge base nodeThe new Knowledge Base node introduced in this new version of Netsparker will show up in the Sitemap left hand side window as a separate node and will be automatically populated during the web application security scan. The knowledge base node will contain generic information about the target website such as list of different file extensions discovered on target website, list of links that point to an external host, list of external scripts used on the website etc. Even though such information might not be directly related to security issues on the target website, it is still useful to know about such things and keep yourself informed of what is in the target web application.

 

 

Off the Shelf Web Application Fingerprinting

Off the shelf web applications such as WordPress, Joomla and Drupal are becoming really popular and are being integrated in business web applications. Although these type of well known web applications are very popular, unless they are kept up to date they are prone of getting hacked. The new version of Netsparker includes a new fingerprinting module that automatically detects such kind of well known web applications and alerts you if the version running on the target website is not the latest version and if there are known security vulnerabilities that could be exploited.

WebAppFingerprint-WordPress-OutOfDate

Server Side Includes Injection Security Checks

Server side includes allows developers to dynamically include content of another page. It has support for multiple directives, for example it can also be used to execute code. Hence they are prone to some dangerous attacks that can lead to remote code execution or arbitrary file reading. Netsparker version 3 has specific web security tests designed to check if the server side includes on the target website can be injected with malicious code.

Easier to Launch new Web Application Security Scans

Even though Netsparker was already well known for being really easy to use, we went the extra mile and simplified even more the new Start a New Scan interface in Netsparker version. We moved all of the options which are typically left as default to the generic application’s settings, such as the number of concurrent connections during a security scan and the enabling or disabling of crawler parsers, which only need to be disabled in very specific circumstances. Launching a new web application security scan has never been easier!

Oracle CHR Encoding and Decoding

The encoder in Netsparker can now also be used to encode any type of input to Oracle SQL Server Char so understanding and fixing of vulnerabilities on web applications which use Oracle server as a database backend servers is now easier than ever before.

Other Improvements and Bug Fixes

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

 

Create Own Scan Policies with Netsparker Scan Policy Editor

$
0
0

In Netsparker Version 3 we introduced the all new Scan Policy Editor that can be used to fine tune web application security scans so they take less time to complete and consume less bandwidth. In this blog post we will see how to use the Scan Policy Editor to create your own custom Scan Policies and save them to use them in future scans.

Scan Policies and the Scan Policy Editor

A Scan Policy is a list of web vulnerability checks that should be launched during a web application security scan. When using the Scan Policy Editor to create a new or modify an existing Scan Policy, you can granularly specify which vulnerability security tests should run during a web application security scan with Netsparker.

Therefore while before you were only able to enable or disable all cross-site scripting security tests, now it is possible to enable or disable specific cross-site scripting vulnerability variants. The same applies for all other vulnerability classes, such as SQL Injection etc. The main advantages of having Scan Policies are:

  • Web application security scans take much less to complete.
  • Less bandwidth is consumed during a scan.
  • Much less stress is generated on the web application during a web application security scan.
  • Create your own Scan Policies and save them to use them in future scans rather than reconfiguring Netsparker each time.
  • You can disable the web security checks that are irrelevant to your scenario. E.g. if you have a MySQL server Netsparker won’t launch MS SQL or Oracle security checks during a security scan.

This update allows us to ship extra signatures in the near future. For example there will be signatures to bypass certain WAFs (web application firewall) and if you are using a WAF then you can customize your policy and enabled those extra checks. If you are not then your scan will not generate extra requests since the security tests for web application firewalls will be disabled. When possible Netsparker will also auto optimize the active configuration on the fly according to the target website for these extra signatures.

Built-In Netsparker Scan Policies

6 built-in Scan Policies are available in Netsparker web application security scanner and can be accessed by clicking on the arrow button in the Scan Policy section, as seen below.

List of built-in Netsparker Scan Policies

The Netsparker built-in Scan Policies are explained below:

All Security Checks: This Scan Policy includes all the security checks in Netsparker. This is ideal if you are not familiar with the target web application.

All Security Checks (MS SQL): If the target web application uses Microsoft SQL Server as database backend, it is recommended to use this Scan Policy.

All Security Checks (MySQL): If the target web application uses MySQL database server as database backend, it is recommended to use this Scan Policy.

All Security Checks (Oracle): If the target web application uses Oracle server as database backend, it is recommended to use this Scan Policy.

All Security Checks (PostgreSQL): If the target web application uses PostgreSQL server as database backend, it is recommended to use this Scan Policy.

Passive Security Checks: As the name implies, this Scan Policy contains only a list of passive and analysis vulnerability checks. Vulnerability checks that might inject your web application, such as SQL injection or Cross-site scripting are not included in this Scan Policy.

How to Create a New Custom Scan Policy

From the Start a New Scan window, which is used to launch a new web application security scan, click on Options and on the three dotted button on the far right of the Scan Policy section, as highlighted below.

launch the scan policy editor

This will launch the Scan Policy Editor which we will use to create and save our new custom Scan Policy Editor. Below is a screenshot of the Scan Policy Editor.

Netsparker Scan Policy Editor

1. Click on the New button for a new Scan Policy.  Once it is created and listed in the Policy Name section, which can be seen in the top left corner of the above screenshot, click on the name to rename the Scan Policy.

2. From the General Settings section (top right section in Scan Policy Editor) you can specify a description for the new Scan Policy, and also specify which modules and parsers should be enabled or disabled when using the newly generated Scan Policy. Below is a list of options:

  • Wait Resource Finder: Set this to True if you would like to wait until the Resource Finder module in Netpsarker finishes looking for hidden directories and resources. Set to False if you would like to start the vulnerability checks scans without waiting for this module.
  • Knowledge Base: Enable or disable the knowledge base checks and node during this web security scan. This might affect what some engines detect.
  • Text Parser: The text parser is used to parse static HTML to find comment and links. Set to True to enable the text parser and False to disable it.
  • Analyze JS / AJAX: This option is used to enable or disable JavaScript and AJAX (client side scripts) analyzers, which are used to execute client side scripts and discover links and other pages which are accessible via such scripts.

3. To select which web security vulnerability checks should be launched during a scan, highlight the test group from the bottom left window Test Groups to see all the web security checks it contains, which show up in the bottom right window Tests. You can enable or disable a whole test group (left window) or individual security tests (right window).

4. Once you are ready with the selection of web vulnerability checks, click OK to save your new Scan Policy.

5. Select your newly generate scan policy for your next web application security scan from the Scan Policy drop down menu in the Options of Start a New Scan window.

 

Viewing all 1027 articles
Browse latest View live