Ferruh Mavituna, Netsparker Founder and CEO, was interviewed by Pulitzer-winning journalist and cybersecurity influencer Byron V. Acohido in May 2018 for the website The Last Watchdog on Privacy & Security. Over the course of their podcast, they discussed why 'digital transformation' makes web applications security paramount, and the position of Netsparker in leading the advance of automated web app vulnerability scanning.

• Byron noted the current success that Netsparker has achieved as a web vulnerability scanner that offers automated elimination of false positives. Netsparker's success can be measured by the size of its clients (Samsung, NASA, Skype), by its recent receipt of $40 million in financing, and by last week winning a prestigious Queen’s Award for Enterprise in the international trade category.
• Ferruh highlighted a number of changes in the world of application security that Netsparker anticipated that have helped to fuel Netsparker's success. For example, there was the move from static websites to interactive web applications, and from on-premises based network environments to cloud based, on-demand, application-driven ones.
• These shifts caused a subsequent transformation in security focus. The attack surface changed from firewall breaches to web application vulnerabilities. And instead of needing security for one application, a company might need it for hundreds or thousands of websites and web APIs. That's why Netsparker's ability to scan at scale is ideal for enterprise-level application security.
• Ferruh concluded by highlighting Netsparker's more recent work in DevOps and integrating security early into the Software Development Life Cycle. This enables vulnerabilities in code to be found quickly – in minutes rather than months – saving enterprises significant finances and enabling them to achieve their deployment deadlines.

Have you ever experienced that sinking feeling when you discover that you've run out of one crucial ingredient for a special meal? It might be a single ingredient, but it ruins the whole dish, doesn't it? In the world of web application security, one apparently small slip-up can compromise the entire security of your web application, even when that mistake consists of leaving out a single character.

This is exactly what happened in CMS Made Simple (CMSMS): one missing character was sufficient to result in an Authentication Bypass, and ultimately Remote Code Execution (RCE).

This article explains the CMSMS vulnerability, which is a perfect illustration of why you should pay very close attention when you code your web application, especially critical parts such as authentication functionality.

What Caused the Authentication Bypass Vulnerability?

CMS Made Simple (CMSMS) is a Content Management System (CMS) written in PHP, and subject to all the beautiful pitfalls that make PHP so unique.

Did you know, for example, that both of these comparisons would return true?

'test' == 0

'test' == TRUE

And that's just the tip of the iceberg. But why would PHP determine that the string 'test' is the same as the integer '0'? Or the same as the boolean TRUE?

The explanation is obvious once you know how it's worked out.

What is Type Juggling?

When using the "==" operator, PHP attempts something called loose comparison (or 'type juggling'). With loose comparison, it's possible for a PHP developer to compare values even if they have a different data type, such as integers and strings. But why would this deliver the weird result in the comparisons example?

Comparing a string to an integer is a little bit like comparing apples and oranges. It is impossible, and the final food metaphor you'll read in this post! PHP somehow has to convert both values to the same data type. When PHP does a comparison, it always attempts to convert the string to an integer first. To do this, it checks the beginning of the string to see if there are numbers it can use for comparison.

The string 'test' doesn't begin with a number. In PHP, this means that it is equal to the integer '0', which explains why the comparison returns true. It's a little different for strings and boolean values. PHP always tries to convert a string to boolean if both are compared. It does this by treating strings with any given content as TRUE. For example 'test' == TRUE, while an empty string is always treated as FALSE.

How to Avoid Type Juggling

The behavior I have just described is obviously undesirable in the many instances in which you want to have an exact comparison of two given values. For this reason, PHP also has the === operator. Since good things come in threes, three equal signs mean that the comparison should take the data type into consideration. If the type differs, PHP will not attempt any conversions; it will return FALSE instead. This is a relatively easy way to deal with PHP's often confusing behaviour when it comes to type comparisons. Simply add a single character.

CMS Made Simple – Authentication Bypass

As I've mentioned, CMS Made Simple is written in PHP, and the loose comparison operator is quite popular in this language. It therefore doesn't come as any surprise that it is used on multiple occasions throughout the code. Of course, there is nothing wrong with that. The real problem arises when it is used on critical comparisons such as password hashes. That is exactly what happened with CMS Made Simple, and I'll explain how I found and exploited this vulnerability.

Thousands of Lines of Source Code

When you are auditing a popular, well-established web application, you are dealing with thousands of lines of code. Most of them won't lead to vulnerabilities, but some of them will, under the right circumstances. A good way to find some vulnerable code in a short amount of time is to concentrate your efforts on critical functions and functionality that is easy to get wrong. It would take weeks to analyse every bit of code starting from index.php, line 1.

One of the areas where critical mistakes often happen is in the authentication functionality of a website. So one of the first files I looked at in CMSMS was /admin/index.php, to find out how it checked whether a user was logged in. Fortunately, the function responsible for this wasn't that difficult to spot.

As you can see in the middle, the function was called check_login. It calls all the other functions that check whether or not the visitor is authenticated. To quickly spot where the function was defined, I used the Find in Folder functionality of my text editor (Sublime Text). It was as easy as searching for 'function check_login('. After a while it returned the following result.

As you see, there are almost two thousand files in CMSMS. So it was important to set some priorities and create a plan for where to start. The search further told me that the function was defined in lib/page.functions.php, which could be opened in Sublime by double-clicking the highlighted line number on the left.

Are We Logged In Yet?

Clicking on the highlighted number displays the actual check_login function. This is what it looks like.

There was a lot going on in this function, so let's try to make some sense out of it. It first tries to retrieve the user id with the get_userid function. If it's bigger than 0, it will assume that the user is logged in. Next, it checks whether or not the Cross-site Request Forgery (CSRF) token is correct. If those checks fail, the function will deauthenticate the user, redirect him or her to /admin/login.php, and abort the remainder of the script execution. So the important values are the CSRF token and the user ID.

Let's first take a look at the user ID. It's returned from the function get_userid. After a quick search in the same file, this was the function.

First, it creates an instance of the LoginOperations class and then calls its get_effective_uid method to return the user ID. To see what it does, we have to go further down the rabbit hole. (Yes, I'm perfectly aware that this sentence is used in every single vulnerability writeup involving source code since the inception of vulnerability writeups involving source code, but at least it's not a food metaphor!)

Finding Authentication Bypasses is a Tedious Task

The search for the get_effective_uid method leads us to a file with the following path: lib/classes/internal/class.LoginOperations.php. Yet again, the actual check doesn't happen in this method.

Instead, it will call the method _get_data which seems to return an array and check the value of an array element against the eff_uid key. If the value does not exist, it will just return the result of calling the method get_loggedin_uid. So to make this check return something other than null, we first have to make sure that _get_data is returning something. Let's take a look at another function.

It seems like we are on the right track. If this check has already taken place, the _data property of this class instance will return its content. However, this is not yet the case. Below this check we see a comment that describes what happens in this function:

"// using session, and-or cookie data see if we are authenticated"

This cryptic comment (not the only weak 'crypto' as we'll discover later) is trying to tell us that CMSMS will try to use $_SESSION (not really user-controllable) to see if there is any data. If that's not the case, it will get its data from $_COOKIE, which holds the data from cookies sent to the server by the client requesting the page. Therefore, it is completely user-controllable. After that, it checks whether any array keys are missing. If everything is fine, it moves on to the _check_passhash method.

Let's take a closer look at this method before we come back to $_COOKIE[$this->_loginkey]. Below you can see _check_passhash:

This looks very promising. It first checks the database to see whether there is a user for the given user id. If there is a user, it will create an MD5 hash consisting of various values. Most of them are user-controllable or static. But the real problem, from an attacker's perspective, is that the password hash that was taken from the database is part of the MD5 hash. To know the hash, you need to know the password. And if you knew the password you wouldn't have to hack anything. You'd simply log in. That's depressing, right? We've come so far, but to authenticate, we still need the correct password. Don't lose hope yet! The checksum from the cookie and the generated checksum containing the database password are compared using loose comparison.

Finally Bypassing CMSMS Authentication Checks

We'd either have to pass the integer 0 or boolean TRUE as $checksum to the function in order to pass the check without knowing the password, providing the hash string doesn't start with a number other than 0. So it's better to use TRUE in this case, as the comparison will always result in TRUE when it's compared to a non-empty string.

However, there is one thing you need to know about PHP input when it comes to $_GET, $_POST and $_COOKIE. There are basically two data types that you can get from these variables: string and array. The latter would work by passing a query such as ?array[]=first_element&array[]=second_element. This seems like a big problem. So let's take a look what data is actually being passed by $_COOKIE. The logic for that is in _get_data(), as illustrated.

It receives the data from a cookie. Its name is saved in the _loginkey property of the current class. Its value is assigned during the construction of the class, as illustrated.

I'm not sure if this hash is in place in order to avoid the problem of having the same login key for different installations or versions of CMSMS, but its values can easily be guessed and some of them are even static. For example, the constant __CLASS__ never changes, and the CMS version can be guessed, as well as the content of __FILE__. The only variable in __FILE__ that is unknown to an attacker is the path to the webroot. If display_errors is not set to 'off', it can be as simple as converting a GET parameter to an array with the method described above. All we have to do is add square brackets after the parameter name: mact[]. It will throw an error in a function that expects a string value, and will display the full path of the file in an error message.

Yet again, we have proof that in certain circumstances, a small information leak can have a huge impact. However, even if we don't achieve a full path disclosure, the value can simply be guessed in most cases. This means that we can easily find the right cookie name, just by trying different webroots and versions. The only problem is that we still need to find a payload that will ensure that we pass the password hashsum check. Since we now know the name of the authentication cookie, we need to look at its content.

Another Reason Not to Use Unserialize

This is yet another example of why you really should read the PHP documentation (as if there weren't enough reasons already). It seems that one of my favorite UNIX quotes applies to PHP as well:

Unix will give you enough rope to shoot yourself in the foot. If you didn't think rope would do that, you should have read the man page.

Let's get back to business.

As we can see, the cookie value is saved in the $private_data variable, as well as in $_SESSION. Before $private_data can be used, it is decrypted using the _decrypt method from the current class. If you were hoping that we were going to crack some advanced encryption algorithms, I'm afraid you're going to be disappointed. You'll see why when you look at the _decrypt and _encrypt methods.

Oh great! It's only encoded with rot13 and base64. In their comment, they actually acknowledged the fact that this function has nothing to do with encryption, but rather with encoding, which is why I'm still puzzled as to why they called it _encrypt. Perhaps they intended to disappoint security researchers and blog readers keen to solve a nice crypto challenge?

I'm kidding! Everything lines up perfectly so far, and having an encrypted cookie would cause a nuisance that might even result in a failed attack. Anyway, str_rot13 and base64 are not the only functions within the two methods. There are another two: unserialize and serialize. To see what's wrong with that, take a quick look at the PHP manual.

It tells us not to pass untrusted user input to unserialize. The reason involves both PHP Object Injection and even Local File Inclusion (LFI) through PHP's autoloading feature.

However, these are not the only vulnerabilities that may arise. Unserialize is infamous for its issues with memory management. Various code execution CVE numbers were assigned due to this function. However, those memory issues are difficult to find, let alone exploit, on different platforms.

Local File Inclusions that are caused by unserialize in combination with an existing  autoloading functionality are almost exclusively restricted to files ending in .php. Also, PHP Object Injection requires existing code ('gadgets') that can lead to dangerous actions. For this to work, the affected classes must contain certain magic methods, like __toString that would be called on to deserialize user input, casting the deserialized object to a string, or more commonly __wakeup which will execute a specific action upon deserializing an object. They also need to have controllable properties and call exploitable functions.

CMSMS didn't contain any obviously dangerous gadgets. But at this point, we don't even need them. While I mentioned before that you can only pass strings and arrays using cookies, it's different with unserialize. We could simply serialize an array containing any data types from boolean to integer, and feed it to unserialize. After they are deserialized, the data types are the same as in the original array. Let's look at the code again.

How to Pass the Checksum Comparison with Type Juggling

Finally we can start building a payload that is able to bypass the CMSMS login prompt for the admin panel.

If we send a base64-encoded, serialized array that was passed through str_rot13 in a cookie (whose name is an MD5 generated by the full path to class.LoginOperations.php, the string CMSMS\LoginOperations and the current version number), we can control the $private_data variable. We can make it an array containing any data with any type we want.

Since both the $uid and $checksum variable we see above come from the deserialized array in the cookie, we can give $private_data['uid'] the value of an integer of '1', and $private_data['cksum'] can be set to the boolean TRUE. It's important to note that administrators almost always have the user id '1'. By setting $private_data['cksum'] to TRUE, the $checksum variable above will also be TRUE.

What happens now is that CMSMS will load the userdata of the user with the id '1' and save it in $oneuser. Then it will generate the password hash, by hashing different values including the received password hash from the database, and save it in $tmp. Among those values, we also have the current user agent and the IP address, which aims to prevent session token theft. However, we can ignore them, due to the loose comparison of $checksum and $tmp using the == operator. Since we have set the $checksum variable to 'TRUE', the comparison is basically like this:

TRUE == '9ab50f27d4201db9b28483ba83c48ebafbb2aa17'

If you recall the comparisons mentioned at the beginning of this post, you may remember that comparing boolean TRUE to any string will alway return true. So even if we don't know the value of $tmp, we can pass the check simply by using TRUE. When we look at the very next comment in the _get_data function, we see this beautiful statement:

// if we get here, the user is authenticated.

Now we know that we have succeeded. However, if we created a cookie and tried to log in, we'd still have one tiny problem.

One Final Setback

This is the error message that tells us that we are missing the 'User key'.

We can see that there is a session variable whose name is the value of the CMS_USER_KEY constant in the code above. It is assigned by retrieving the cookie with the name stored in the constant CMS_SECURE_PARAM_NAME. When searching for the code that defines the secure param name, we end up in the file lib/include.php.

The value is just the string '_sk_'. I've seen this name before. It turns out that this is the name of the CSRF token parameter. In order to get rid of the error, we have to pass a cookie named _sk_ with any string we want (for example the string 'pwned'). This will make 'pwned' our CSRF token value. When we return to the admin panel, we will be logged in!

Writing an Exploit to Gain Remote Code Execution

Now that we are logged in, we can perform any administrative action we want. However, often this is not enough. In order to pivot into an internal network or steal sensitive data, we actually need a proper shell. In PHP, the default way to do this is to upload a file with the .php extension, and then execute system commands. This is easier said than done.

Even though we can upload any file using the file manager, we can't upload files with the .php extension. This is because the input is filtered and any file with an extension beginning or ending with php will be rejected. We could circumvent this restriction by uploading an .htaccess file, and force any other extension to be recognized as a PHP file, for example .pwn or (since it's sometimes already registered) use .pht as the extension instead. But we can't depend on this being the case for every server, and .htaccess files are often disabled. However, it's possible to bypass the check in Windows. Let's take a look at the filter.

This will take the text after the last '.' character and save it in $ext. After that, it will check if $ext begins or ends with the string 'php'. One trick for Windows is to save the file as 'exploit.php.' instead of 'exploit.php'. Notice the additional '.' at the end of the first variation. The check will still try to retrieve the string following the final period. This is now empty, since nothing comes after the final period. So it doesn't contain 'php' and the check passes. However, this file would no longer be recognized (at least in Linux) as a PHP file, because the extension is missing. Windows, on the other hand, does us a huge favor. To see why, look at the commands I issued.

As you see, I tried to save the text 'hello' in the file 'exploit.php.'. But when I listed the contents of the directory, it was actually saved as 'exploit.php' without the extra period. By employing '.php.' as the extension, we bypass the filter but still have a valid php extension. The only drawback is that this behaviour doesn't work in Linux. Since it's not useful for writing a reliable exploit for both Windows and Linux, we need to find another way to upload files.

CMSMS has a lot of modules that can extend the functionality of the CMS. We can actually upload our own from within the administrator panel. These files are uploaded via an .xml file that describes all the folders, files and content that are needed for the extension to work. This will be our method of uploading a PHP file containing malicious code. We can have an extension with any name containing our shell.

Since the metasploit framework is perfect for this kind of automated exploit, I have written a module for it. Below you can see it in action.

What You Can Learn From CMSMS Mistakes

Forgetting even a single character can have a huge impact on the security of your application. Unfortunately, writing web applications is not always easy. There is a lot to keep in mind and a lot more to mess up. This is why it's important to know the ins and outs of the programming language of your choice, and to read the documentation regarding dangerous functionality to understand its implications.

I'm sure that the developers of CMSMS knew about loose comparison and its pitfalls, but just weren't paying close attention at the time. But this is exactly what makes this type of vulnerability so dangerous. If you don't pay close attention, you end up introducing a flaw that is so easy to exploit, it's like taking candy from a baby. Whether or not this was a food metaphor is left to the judgement of the reader.

The good news is that fixing it is straightforward. You don't need to be a web security expert to be able to use the '===' operator on critical comparisons. In most cases, it doesn't take a long time to search for the '==' operator in your code and replace it where you need to. So as easy as it is to exploit those vulnerabilities, it is just as easy to fix them.

There are few topic that developers universally agree on. One example that often leads to heated discussions is the choice of the right source code editor. You may be a Vim fanatic or maybe you prefer the simplicity of Nano or the extensibility of Visual Studio Code. Meanwhile, others argue over whether Vim can be considered an editor at all. Sometimes it's dismissed as a shortcut memory game, where there are – by design – no winners. But, I digress.

What's actually important is that while there are many controversial topics in the programming profession, there is also occasional consensus. In this blog post, we examine a simple rule in web application development:

Separate as much application logic from the HTML code as you can!

Why Do You Need Server-Side Templates?

To explain why it's considered bad practice to mix HTML with application logic, consider the following example. Let's say you want to serve the following code to your users:

This is not just some static HTML code. The username is taken from a cookie and is automatically filled in for you. That way you don't have to type it in if you have previously logged into this website. But that is also a problem. You have to somehow insert the value into the HTML file. There's a right and a wrong way to do this. But, first, let's start by asking why you'd do this.

Below is a screenshot depicting a completely wrong approach to solve that problem.

There are many issues with this code and not only because the author didn't even try to sanitize the input. HTML and PHP are mixed in a convoluted, almost incomprehensible, way. Parts of the HTML code are spread over several functions. However, the real struggle begins when you try to change anything in the HTML code – like adding CSS classes or changing the order of the HTML tags.

This example is obviously deliberately badly written and it could be better formatted. But, in large code bases especially, even well formatted code that is written in a similar way quickly becomes unmanageable. This is why we need templates.

What Are Server Side Templates?

Server Side Templates provide an easier method of managing the dynamic generation of HTML code than the mess we have described above. The big advantage is that you can generate dynamic HTML pages that, on the server side, read like static HTML. Let's see how our convoluted code looks when we use Server Side Templates.

This is a big improvement on the previous code. However, it's still static. In order to display the correct information instead of the curly bracket placeholders, we need a template engine that replaces them. The code may look like this on the backend.

It's immediately clear what this code does. It loads the login.tpl file and assigns variables that match the name of the ones in the template (the one with the curly brackets). Then, using the show function, it replaces them accordingly and prints the HTML code. However, we have added additional functionality to the template which can reveal to the user how long the template took to render.

Why Server Side Templates Can Be Dangerous

It looks like pretty harmless functionality and it actually is. But if you study it again, you can see that it is possible to execute native functions from within the template. This implies that if attackers are able to write such an expression into a template file, they can effectively execute arbitrary functions. But it doesn't necessarily need to be a file that contains your template. Under the hood, a template engine would convert the file to a string anyway in order to replace the expressions with their result. That's why many template engines also enable you to pass a string to them instead of the location of a file.

You can compare this to require() and eval() functions. require() includes the file and executes it; eval() executes a string instead of a file. You probably know that it's a bad idea to pass unsanitized input to eval(). Every decent book about programming should mention this at least a dozen times. But this is often not considered when you deal with a template engine. That means sometimes you can see code like this.

This code shows that we have user-controlled input inside a template string, which in turn means that users can execute template expressions. An example of a malicious expression could be as simple as {{system('whoami')}}, which would execute the whoami system command. Therefore, a template injection can easily lead to a Remote Code Execution, in the same way that passing unsanitized input to the eval function does. This is what we call a Server-Side Template Injection (SSTI). This is a pretty obvious example, but bugs can be even more subtle, for example by concatenating many different components of an application together before passing them to the template engine and by forgetting that some of them may contain user-controllable input.

How Can I Protect Web Applications From Server-Side Template Injections?

• In order to protect against this kind of vulnerability, you should treat the string loading functionality with the same care as the eval function. Wherever possible, load static template files.
• But beware: we have already established that this functionality is similar to a require function call. Therefore you should protect against Local File Inclusion (LFI) vulnerabilities here as well. This means that you should not allow users to control the path to such a file, or its content.
• In addition, whenever you need to pass dynamic data to a template, don't do it directly within the template file, but use the template engine's built-in functionality to expand expressions to their result instead.

To determine whether your application is susceptible to SSTI, scan your website today using the Netsparker Web Application Security Scanner.

This year, Netsparker will exhibit at Black Hat USA 2018 in Las Vegas, USA. The Business Hall will be open from August, 8-9 at the Mandalay Bay Convention Center.

Join Us at Booth #1171 at Black Hat USA 2018

Members of our team will represent Netsparker at booth #1171. Our team will be available to answer any questions you might have about automatically detecting vulnerabilities in your websites and web applications.

Visit the Black Hat Website for a copy of the agenda and more information about the event.

We look forward to meeting you there!

What is osquery?

osquery is a tool that exposes an operating system as a high-performance relational database. It enables developers to write SQL-based queries that explore operating system data. With osquery, SQL tables can be created to help represent otherwise fairly abstract concepts, such as:

• Running processes
• Loaded kernel modules
• Open network connections
• Browser plugins
• Hardware events
• File hashes

For example, if you wanted to find out to which IP the hostname localhost resolves, you could simply use an SQL query like this:

SELECT address FROM etc_hosts WHERE hostnames = 'localhost';

You can access the list of predefined tables here: https://osquery.io/schema/2.11.2.

How Does osquery Work?

Here are some examples of what you can do with osquery and why it's such a useful utility. Some of the data below could not be retrieved without the tedious parsing of system files or, even worse, without employing dangerous system commands:

• List users
• Get the process name, port and PID for all processes
• List logged-in users

Let's examine each type of data in turn.

List Users

You can list most of the information in /etc/passwd using this simple query:

SELECT * FROM users;

Get The Process Name, Port, and PID for All Processes

This would usually involve a system command, but now you can simply use the query below:

SELECT DISTINCT processes.name, listening_ports.port, processes.pid FROM listening_ports JOIN processes USING (pid);

osquery Injection

osquery Injection is a vulnerability caused by a misuse of the library, just like SQL Injection or Memcache Injection. The official Python library was published by Facebook. Unfortunately, it does not use a mechanism like Prepared Statement. Therefore, when user input is placed in any part of the query, malicious queries can be executed and vulnerabilities can be exploited by the attacker.

This is how it might be implemented:

from flask import Flask, request
app = Flask(__name__)
import osquery

@app.route("/")
def prod():
   name = request.values.get('username')
   instance = osquery.SpawnInstance()
   instance.open()
   result = instance.client.query("select username, description from users where username='"+name+"'")
   status = result.status
   results = result.response
   output = str(status)+"<br>"
   output += "<table border='1'>"
   output += "<tr><td>username</td><td>description</td></tr>"
   for user in results:
       output += "<tr><td>"+user['username']+"</td><td>"+user['description']+"</td></tr>"
   output += "</table>"
   return str(output)
if __name__ == "__main__":
   app.run(host='0.0.0.0', port=35275, debug=False)

This code simply provides some information about the user, by including the username from the GET method in the query.

An easy way to test our vulnerable application is to deploy the docker container using these commands:

$ git clone https://github.com/Om3rCitak/osquery-injection.git
$ cd osquery-injection/
$ docker-compose up

The code should work just fine after this process. Now you can access the application you deployed from the following address:

http://{docker_ip_adress}:35275/?username=systemd-network

Be careful with the code, as it contains a rather severe vulnerability. In case you didn't spot it right away, the input we received from the user was included in the query, as illustrated:

select username, description from users where username='"+name+"'

So, if we send a request like the following, our query will change and as a result we will get the details of the systemd-network user:

URL: http://{docker_ip_adress}:35275/?username=systemd-network

Query: select username, description from users where username=’systemd-network’

If we want to exploit this injection vulnerability, we have to retrieve data from other tables. This is similar to a default SQL Injection vulnerability. All we need is:

• The column count for the query
• The table names

We need a number of columns for a UNION-based attack. In osquery, we can access data from several tables by using the UNION clause. The only condition is that the number of columns in each of the two queries we combine must be equal.

Retrieving the Column Count

As in standard SQL queries, the ORDER BY clause is also available in osquery. Usually, it's used to sort the results according to a specified column name, such as ORDER BY name.

However, since you can specify a number instead of a column name, this clause is especially interesting for SQL injections. The number corresponds to the position of a column in the select list. And, just as in an SQL Injection, we can use this behaviour to determine the number of columns using the ORDER BY clause in our osquery injection.

If you abused this behaviour in an SQL injection, you would usually type in a large number right after the ORDER BY clause. An example might be ORDER BY 50. If this number was too big, you would get feedback, such as an error, an empty page, or missing content. You would then divide the initial value by two and try again. In our example: ORDER BY 25. Repeating this process multiple times, though tedious, would help you discover the correct number of columns.

In osquery, the situation is much better from an attacker's point of view. The second we send a number that's bigger than the actual column count, it immediately provides us with the number of columns. You can see this in the example below:

http://{docker_ip_adress}:35275/?username=systemd-network’ ORDER BY 999 --

We sent the value 999 in the ORDER BY clause (see image). It returns the following message:

'Error running query: 1st ORDER BY term out of range - should be between 1 and 2'

Since the ORDER BY value we need to send can only be between 1 and 2, we can assume that our column count is 2.

The double dash (--) included at the end of some of these queries is simply a way to start a comment. This effectively removes any part of the query that follows the double dash.

http://{docker_ip_adress}:35275/?username=systemd-network’ union select 1,2 from processes --

In the screenshot, we can see that the two additional columns are printed as output.

Finding the Correct Table Names

Finding table names is a much easier task than finding the column count. This is because the predefined tables are publicly available at the following address:

https://osquery.io/schema/2.11.2

Unfortunately, there is no way to find custom tables that have been added afterwards. In an MySQL injection, you can access the table names via information_schema. However, there is no such structure for table names in osquery.

Accessing Other Tables

To detect the operating system and its version that osquery is working in, we send a query like this:

http://{docker_ip_adress}:35275/?username=systemd-network’ union select build_platform,version from osquery_info --

To learn which processes are running on the system, we send a query like this:

http://{docker_ip_adress}:35275/?username=systemd-network’ union select cmdline,path from processes --

To find the PIDs of listening ports and ports listening services, we send a query like this:

http://{docker_ip_adress}:35275/?username=systemd-network’ union select pid,port from listening_ports --

To find out all users in the system, we could send the following query:

http://{docker_ip_adress}:35275/?username=systemd-network’ union select username,description from users --

However, since our query is still in the users table, we can use a short and elegant solution like this:

http://{docker_ip_adress}:35275/?username=systemd-network’ or 1=1 --

Resources & Further Information

• https://osquery.io/
• https://github.com/facebook/osquery
• https://github.com/osquery/osquery-python
• https://github.com/kolide/docker-osquery
• https://www.digitalocean.com/community/tutorials/how-to-monitor-your-system-security-with-osquery-on-ubuntu-16-04

Ferruh Mavituna, Founder and CEO of Netsparker, was interviewed by Paul Asadoorian for Enterprise Security Weekly #98. They talked about the differences between penetration testing versus automatic, dynamic scanning, how to balance both approaches and why there is a need to automate web application security in enterprises. During the show, Ferruh explained:

• Security is not something you can tack on at the end. The web development landscape has changed since the traditional Waterfall approach, where pen testing was scheduled around two months before release. Agile enterprises deploy code to live environments multiple times a day. Netsparker has automated as much of the SDLC as possible, since this new approach does not operate in discrete 'stages' of development.
• Addressing vulnerabilities at the earliest possible point in an Agile SDLC enables developers to learn as they discover, then fix, vulnerabilities, reducing the chance of similar vulnerabilities being repeatedly introduced. Paul added that this also avoids the twin Waterfall problems of a developer not having looked at code for months, and the many dependencies, all of which would also need to be unravelled. And, it's cheaper too!
• Paul then switched the conversation to black box testing, asking if Netsparker was continuing on that path, in Agile and DevOps contexts. Ferruh replied that static integration is becoming popular, where the system suggests that a developer could be introducing a vulnerability as they write the code. But, he highlighted one huge disadvantage – it produces lengthy reports, containing many false positives, that are simply ignored.
• In contrast, they discussed the extremely accurate results of dynamic testing. Ferruh said that Netsparker's unique technology safely exploits vulnerabilities and supplies a proof of exploit for each one, meaning only confirmed vulnerabilities are flagged to developers as issues. Ferruh stated it was an issue of trust, really. Developers can trust that vulnerabilities detected by Netsparker are real, and must be addressed.
• Paul then asked whether Ferruh had observed teams adding information into their dynamic scanner that would help it become, not only more accurate, but more comprehensive. Ferruh confirmed that developers are very good at contributing this information (for example, importing a wsdl or swagger file), the same information they would give to a penetration tester, which helps improve the work of the dynamic scanner.
• They then discussed how some external, public-facing applications can additionally benefit from crowd-sourced pen testing, and even bug bounties. But they concluded that the time and hassle of running a bug bounty program with financial incentives, all of whose discoveries need to be compensated, collated and investigated, could be counter-productive (and discovered anyway by dynamic scanners).
• Finally, they discussed how dynamic scanners, such as the Netsparker web application security scanner, help enterprises create a security workflow, one that included a facility that assigns vulnerabilities to developers, tracks the progress of the fixes, and retests or reassigns them. Security testing is integrated into the SDLC, in both development and live environments, which matters more the more websites you manage.

In 2015, Microsoft released the Edge browser. When it was first developed, it was named Project Spartan.

Unlike Internet Explorer, Edge supports a wide range of modern security measures such as Content Security Policy (CSP), as well as modern JavaScript and CSS features. Ditching the development of Internet Explorer and starting over with a modern browser like Edge brought many new security advantages – but also, some problems.

One thing that's often overlooked in similar, new development projects is the knowledge gained from years of small security fixes on the original product. Those experienced with the inner workings will know that your team would probably initially get more wrong than right during the process of developing a new browser today.

The reason for this is that browser security is under constant redevelopment as new hacks arise, since browsers are viewed as one of the richest sources of potential attack surfaces by hackers and security professionals alike. Small security holes that used to lead to the leakage of user data in browsers have been resolved over the years. Some were more severe than others, but most of them weren't immediately obvious in the first place. It is these security fixes, and the knowledge that comes with it, that may get lost when redesigning a web browser.

That might explain why Microsoft Edge was the only browser I found that was vulnerable to this flaw.

Note: this vulnerability has already been fixed by Microsoft.

Who is at Risk From This Microsoft Edge Vulnerability?

I've successfully tested my exploit on Microsoft Edge 40.15063.0.0.

How Can You Steal My Local Files?

Let's first think about why I shouldn't be able to steal your local files!

The Same Origin Policy (SOP) would prevent https://attacker.com from reading file://C:/your/stuff.txt, for example. The reason is that they have different origins. In order to read data using a JavaScript-issued request, the protocol, the hostname and the port need to match. However, file URLs are a little special. The file:// protocol and the https:// protocol are obviously different, which is why attacker.com can't read your local files.

But what if we're dealing with two file URLs neither have a hostname nor a port? They only have the file protocol scheme and a path. This means that the two file urls would automatically be from the same origin because:

• The port matches: Both have no port
• The hostname matches: There is no hostname on both of them
• The protocol scheme matches: Both use the file:// scheme

In other words, if the browser developers wouldn't take the special format of file:// urls into consideration, it would be possible for me to read the content of any local file if you simply opened a malicious HTML file saved on your machine!

You might conclude that this is not a very convincing attack vector – perhaps because you've never download random HTML files. In addition, Windows might block the file you just downloaded, since it came from another computer. At least, this was the case when I tested the attack.

Is This a Realistic Threat? Or Is It a Theoretical Scenario?

Do you think an attacker could somehow convince a potential victim to download a HTML file and execute it?

Due to the existence of another attack vector, it turns out that this is not merely a theoretical scenario. If you can't deliver your HTML file through the browser, why not simply mail it to your victim? In the last few years we've become all too cognisant of the fact that it can be A Very Bad Thing to open unknown attachments such as .exe files, .js files and even Word documents. But HTML files? There is no obvious immediate danger. After all, we request many HTML files in our browsers every day.

I drafted an email from another computer, added the file as an attachment and then opened the attachment in the Mail and Calendar app. Much to my surprise, it worked. I expected that the app, like the Edge browser, would block the attachment. But this was not the case at all. When I sent the email as an attachment and waited until a user opened it, it would immediately send local files of my choosing to my server, where I could store and read them. There is probably no antivirus program that would recognize my file as malicious, and, I could extract the files over a secure HTTPS connection. This is what makes this attack so stealthy! The Windows Mail and Calendar version where I tried my exploit was version 17.8600.40445.0 (This bug was reported too).

But there are other ways to deliver the file, depending on the target's installed programs.

How Can I Protect My Files?

The only way to protect yourself is to update to the latest versions of the Edge browser and Windows Mail and Calendar applications. And, of course it's best to never open attachments from unknown senders, even if the extension doesn't initially appear to be malicious.

But this was a very theoretical post. If you want to see my exploit in action, you can watch my proof of exploit video.

Each year, we publish a set of statistics summarizing the vulnerabilities we find in open source web applications. Our tests form part of Netsparker's quality assurance practices, during which we scan thousands of web applications and websites. This helps us to add to our security checks and continuously improve the scanner's accuracy.

This blog post includes statistics based on security research conducted throughout 2017. But first, we take a look at why we care about open source applications, and the damage that can be caused for enterprises when they go wrong.

Why Do Workplaces Use Open Source Software?

The reason for the rise in popularity of open source software in the business world is financial: your enterprise is getting great software for free. Some enterprises resonate with the open source philosophy of collaboration and giving back. This helps explain why big companies like Twitter, Tumblr, Netflix and Pinterest use and advocate for open source.

Netsparker has a natural interest in the security aspect of open source software, and also a very question; since the source code of open source projects is publically available, does that make these applications more or less secure than proprietary or closed software?

What Happens When Open Source Goes Wrong?

The global average cost of a data breach in 2017 was $3.62 million. In May to July of 2017, Equifax suffered a massive cyber-security breach, with attackers accessing hundreds of millions of customers' personal data. Although they announced this breach in September 2017, Equifax was informed in 2016 that their website was vulnerable, and was even told which vulnerabilities to check.

Hackers exploiting open source Apache Struts vulnerabilities were blamed for the Equifax breach. Although a deserialization vulnerability in the REST plugin of Apache Struts was initially blamed, an OGNL Expression Injection vulnerability in Struts was found to be the cause for the breach.

Even though a vast amount of personal data was being exposed due to the Equifax breach, a significantly higher number of users were potentially affected by another security bug in readily available open source software. ROBOT (Return Of Bleichenbacher's Oracle Threat) is a type of attack that revives a 19-year old vulnerability. Bleichenbacher’s RSA vulnerability is still very prevalent in the Internet and affected top domains like Facebook and Paypal, along with many other vendors and open source projects. In December 2017, Netsparker released a hotfix version of our web application security scanner that included ROBOT security checks.

Why Does Netsparker Care About Open Source?

One of the best ways to demonstrate the effectiveness of Netsparker web application security scanner is to test it against a wide variety of web applications used on the web. So our security researchers scan a great variety of open source web applications including: shopping carts and e-commerce solutions, social networking web applications, forums and blogs. The complexity of the testing environment increases when you consider the big number of languages used to create web applications, such as: PHP, Java, Ruby on Rails, ASP.NET, Node.JS, Python and other frameworks.

The only reason – aside from an awesome team of dedicated Security Researchers – that we are able to scan so many web applications and detect so many vulnerabilities across such a wide range, is because automation is at the heart of the Netsparker's web application security scanning technology.

There are a couple of neat side benefits. Open source applications development teams get free security testing, empowering them to write more secure code. If you'd like to conduct your own, free, automated web application security testing, and read more about how we're huge supporters of the open source community, see our offer of Free Online Web Security Scans For Open Source Projects.

What Did Netsparker Discover About the State of Open Source Security In 2017?

What Is The Most Prolific Vulnerability in Open Source Applications?

The most predominant vulnerability discovered in open source web applications was Reflected XSS. This accounted for almost 70% of the overall number of reported vulnerabilities. All kinds of Cross-site Scripting (XSS) vulnerabilities ranked as number seven in the OWASP Top 10 List for 2017.

How Many Web Applications Did We Scan in 2017?

• The total number of web applications we tested and scanned in 2017 was 154, an increase of over 48% from our last report
• The most popular web application frameworks or languages in which scanned apps were developed are PHP (124), .NET (14) and Java (10)
• The most popular back-end database servers used by these scanned applications were MySQL (86), Microsoft SQL Server (13)

What Were the Vulnerability Findings for 2017?

What is of most interest to us is the numbers of vulnerabilities we found in these web applications.

• The number of vulnerable web applications was 59. This is over 38% of all the web applications we tested.
• The total number of vulnerabilities Netsparker identified in these open source sites was 346.

Which Vulnerability Types Were Detected?

The web application vulnerabilities Netsparker discovered are listed in the table below.

Around 88% of the total vulnerabilities were either of Critical or High Severity. For more information on how Netsparker defines severity levels, see Web Application Vulnerabilities Severities Explained.

How Has the State of Web Application Security Changed Since 2016?

Compared to our findings from last year's open source testing (see our previous Statistics About the Security State of 104 Open Source Web Applications), it's clear that XSS vulnerabilities remain, by far, the most common type of vulnerability to be found in open source web applications. The reason for this is that developers who are keen to provide rich interaction in modern web applications use JavaScript in the client-side.

Whereas last year SQL Injection vulnerabilities came in second place, this year Frame Injection vulnerabilities have replaced them. The top development languages, frameworks and database servers remains the same.

What Action Did the Open Source Applications Take?

If you consult our Web Application Advisories by Netsparker list, you can see that we published 32 advisories in 2017. In addition, there are 28 in pending mode. Of these 32, 28 vendors were contacted. Out of the 59 reported web applications with vulnerabilities, only six were fixed. The number of advisories with multiple vulnerabilities was three.

Would Your Open Source Project Benefit From Free Web Vulnerability Scans?

Based on our latest statistics, a randomly-selected web application may include an average of 2.25 vulnerabilities. Developers could eliminate many of these by taking security best practice into account during the SDLC.

Does your team have time to conduct penetration testing to find them all? And, do you know what to do, to remove the vulnerability, and determine whether it is gone? Would you like to have access to an automated web application security scanning solution that would detect them all – and offer remediation recommendations?

Netsparker offers Free Online Web Application Security Scans for Open Source Projects. This is our token of appreciation to all the developers in the open source community and Netsparker's way of giving back to you. Open source projects such as OpenCart have already used our free, automated web application security scans with great success. Why not you, too?

Useful Resources

Web Application Vulnerabilities Index
Web Application Advisories by Netsparker
State of Open Source Web Applications

A few days ago, Reddit announced that they had been the victim of an elaborate hack attack and data breach. The attackers accessed the email digests from August 2018 and the entire 2007 database backup. The backup included old salted and hashed user passwords, usernames and their email addresses. The attackers also compromised a few Reddit employee accounts by intercepting the SMS used in two-factor authentication (2FA).

Although our knowledge about the attack is limited to what Reddit has disclosed, we can still analyze the incident from a web security perspective.

Storing Hashed and Salted Passwords

Protecting passwords by employing salted password hashing is a web security measure that really pays off in the event of a website breach. This tactic makes it more difficult for attackers to retrieve them in a usable form, providing that the passwords are strong enough. In case users use the same passwords for other accounts, this prevents attackers from taking over the accounts on those platforms as well.

Reddit announced that if users are found to be actively using the same hashed passwords as the stolen ones, they will be asked to reset them. Regardless, users are advised to change their passwords as a safety measure if they’ve been using the same one since 2007 (refer to our customer survey on online risky behaviour for more information on how end users use passwords etc).

Two-Factor Authentication and Multi-Factor Authentication (MFA)

Reddit employees were right in enabling 2FA to secure their login process. Two-Factor Authentication is an additional authentication feature that requires the user to provide a proof of knowledge, possession or inheritance by using one or more of the following:

• Knowledge - something the user knows (password, PIN code)
• Possession - something the user has (telephone, OTP, Token Generator)
• Inherence - something the user is (biometrics, fingerprints)

The interception of SMS text messages, using techniques such as SIM-swapping or abusing weaknesses in the SS7 protocol, has been practised by criminals for quite a while.

Following this recent incident, Reddit also announced that they will get rid of SMS-based Two-Factor Authentication in favor of token-based 2FA. Users will need to enter a token generated by an authenticator application (usually installed on their phone) in place of the SMS verification code, as part of their secure login process.

An Excellent Example of Proper Logging and Monitoring

Perhaps the most controversial item on the OWASP Top 10 List for 2017 was the Insufficient Logging and Monitoring category. A similar category is listed in the OWASP Proactive Controls List - Implement Logging and Intrusion Detection. While the implementation of the logging mechanism is listed as a recommended measure in the Proactive Controls list, the improper implementation of this mechanism is listed as a vulnerability in the Top 10 list.

Keeping in mind that the average time between a successful attack and its detection is no less than a whopping 191 days, Reddit did a pretty impressive job by uncovering the attack on June 19 - only about 1-4 days after the attack (June 14-18) took place.

For further information on the attack, see the full Reddit announcement.

Given the increasing number of data breaches, you won't be surprised to read that this blog post is about yet another data breach. Unusually, however, this time the looting did not involve a database. The hackers used a different, perhaps more dangerous, trick instead.

In this blog post we will use the Ticketmaster UK data breach as an example to explain how your developers can use the browser security features to build more secure web applications.

What happened in the Ticketmaster UK data breach?

On June 27, 2018 Ticketmaster UK announced a data breach incident, that didn't directly affect the Ticketmaster server. It was actually a different company, Inbenta, that was affected. However Inbenta provided the live chat systems used on the Ticketmaster website.

On discovering malicious JavaScript code, Ticketmaster immediately disabled all Inbenta products across Ticketmaster's websites. Ticketmaster announced that less than 5% of their customers were affected and that the North American customer database remained intact.

The Turkish branch of Ticketmaster, Biletix, released a similar announcement about the attack. However, in August, security researcher Mert Sarıca analyzed the malicious code and pointed out that Turkish users might not have been affected by the incident either. What had happened was that malicious Javascript code was placed into the inbenta.js JavaScript library hosted on Inbenta's website. Its code acted by collecting the data of input fields on the checkout page and submitting it to the attacker's Command and Control (CC) servers. Input names and values were concatenated and encoded in base64 before being submitted to the attacker's CC server.

It's worth noting that this is a rare example of an occasion where one of JavaScript's unexpected limitations actually prevented a security incident - at least for Ticketmaster's Turkish users. When the Satın Al (checkout) button was clicked, the btoa JavaScript function couldn't encode the Turkish characters in the button name and returned an error. Turkish users dodged a bullet, as although the data was accessed, it could not be submitted to the hacker's Command and Control server.

Chances are that Biletix won't be as lucky the next time. We must ensure that our websites stay secure, even when we are using third-party apps and services on our website. Luckily there is a way to ensure integrity of remote resources, such as external JavaScript files.

Using SRI to ensure external website files are not tampered

How can you ensure that external javascript or CSS files haven't been edited by an attacker? And is there anything you can do to prevent an altered file from being loaded in your users' browsers?

The answer is yes; and the method is by adopting Subresource Integrity (SRI). SRI ensures that these third-party resources are loaded without modifications. You can validate the integrity of the external files hosted on the website by encoding one or more of their SHA-256, SHA-384, or SHA-512 hashes in base64 in an integrity attribute added to script or link tags. SRI compares these expected hash values with those of the loaded resources. If there's a mismatch, the browser throws an error in its debugging console and halts the loading of the affected resource.

<script src="http://my2cdn.com/myscript.js" integrity="sha256-0URT8NZXh/hI7oaypQXNjC07bwnLB52GAjvNiCaN7Gc=" crossorigin="anonymous"></script>

What Happens if There is a Mismatch in the Hash Values?

If the hash values do not match, the script or style files won't be loaded. It’s important to note that, this verification and denial process only happens in browsers that support SRI. This is what an SRI error looks like.

Of course, the quality of the protection SRI provides is dependent on your ability to review the external JavaScript code you load into your website. If the JavaScript code contains vulnerabilities or a backdoor at the time you activate SRI, the data of your users remains at risk.

Subresource Integrity (SRI) could have stopped Ticketmaster’s data breach

Had Ticketmaster implemented SRI for their third-party script and style resources, the browsers would have stopped the loading of the scripts, therefore preventing malicious code from being executed.

For a detailed explanation of SRI, see Subresource Integrity (SRI) for Validating Web Resources Hosted on Third Party Services (CDNs). When you scan your website with Netsparker it checks if your website has SRI configured and recommends remedial actions.

Whitelisting sources with Content Security Policy (CSP)

Since the release of its first version in November 2012, CSP has acted as an additional client-side security layer that defends websites against vulnerabilities such as Cross-Site Scripting, Clickjacking, Protocol Downgrading, and Frame Injection.

CSP prevents the execution of any unexpected code and inline scripts by whitelisting trusted external sources as in the following example.

Content-Security-Policy: script-src 'self' https://apis.google.com

However, it's also possible to whitelist a hash value instead of a URL, as we've already seen when we discussed SRI.

Content-Security-Policy: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='

The Ticketmaster incident might be a little more complicated than we initially assumed, as even though there is CSP that can restrict where data is being loaded from, Ticketmaster likely whitelisted Inbenta's website, in order to use its library. In this case, another feature of CSP might be useful. CSP's connect-src directive could save the day in many incidents involving JavaScript malware.

Using the connect-src directive

The connect-src: directive restricts the resources that can be loaded via interfaces such as XHR, WebSockets and EventSource.

Content-Security-Policy: connect-src 'self' https://thirdparty.com/end-point;

The JavaScript malware won't be able to function as intended when only Ticketmaster's own endpoint URLs and the third-party service URLs are whitelisted. The malware will attempt to transfer the data it acquires to the attacker's CC, but the request will be blocked by CSP's connect-src directive.

But there is a catch. If the attacker specifically targets Ticketmaster, he may use other techniques to transfer data, such as form submissions or redirects, which are less stealthy, but still result in the extraction of user data. In either case, it doesn't hurt to implement a strict Content Security Policy, as it can often save you from serious trouble without having to rely on JavaScripts quirks.

If the report-uri directive is passed together with the connect-src directive, the browser will not only block the unexpected request, but will also report the violation to the specified URL in report-uri. This report will be sent in the JSON format and will include:

• The page on which the violation occurred
• The requested source that triggered the block
• The data that the malware attempted to transfer

Content-Security-Policy: connect-src 'self' https://thirdparty.com/end-point; report-uri https://www.example.com/report-uri

"csp-report": {
"document-uri": "http://example.org/page.html",
"referrer": "http://evil.example.com/",
"blocked-uri": "http://evil.example.com/evil.cc",
"violated-directive": "connect-src 'self' https://apis.google.com",
"original-policy": "connect-src 'self' https://apis.google.com; report-uri

http://example.org/my_amazing_csp_report_parser"
}
}

For further information on how to implement CSP on your website refer to our guide to Content Security Policy (CSP) on our blog.

Using browser security to enhance website security

No protocol, policy or system is perfect. But as this article highlights, by using a collection of browser security features and protocols such as the Subresource Integrity (SRI) and Content Security Policy (CSP) you will make your websites more secure and less prone to hack attacks and data breaches.

PHP is often referred to as a 'loosely typed' programming language. This means that you don't have to define the type of any variable you declare. During the comparisons of different variables, PHP will automatically convert the data into a common, comparable type. This makes it possible to compare the number 12 to the string '12' or check whether or not a string is empty by using a comparison like $string == True. This, however, leads to a variety of problems and might even cause security vulnerabilities, as described in this blog post.

The PHP Language Has Its Peculiarities

There are lots of reasons not to like PHP. One of them is its inconsistent naming of built-in functions. This becomes apparent when you look at the functions that are responsible for encoding and decoding data. For one, there is base64_decode or base64_encode with underscores in the function name. However, urldecode and urlencode are named differently, for no apparent reason.

Another thing is that the order of common parameters varies greatly among different functions. Yet again, there are two examples where this is quite obvious:

• bool in_array ( mixed $needle , array $haystack [, bool $strict = FALSE ] )

• mixed strpos ( string $haystack , mixed $needle [, int $offset = 0 ] )

You see how both of these functions are described in the PHP manual. While in_array takes data to search as the first parameter, strpos takes it as the second one. When you forget this, it's easy to make mistakes and write a strpos check that's almost never true. Those issues are often hard to find and debug. But, by far, this is not the only problem you can encounter when dealing with PHP!

Type Conversions Made Easy

Since we've already found an issue with strpos, let's see if we can also find one for in_array.

Consider the following PHP code, which can be used to find a value in an array.

Code

$values = array("apple","orange","pear","grape");
var_dump(in_array("apple", $values));

Output

bool(true)

There are four elements in the $values array: "apple", "orange", "pear" and "grape". To determine whether the value "apple" is among them, we pass it to in_array. The function var_dump prints bool(true) as result of this search, since "apple" is indeed a part of the $values array. If we passed the value "cherry" to the function, var_dump would print bool(false) since it's not found in the array.

Things are going to get a little confusing at this point. It's pretty obvious what should happen when we pass the number '0' to the array. Just from looking at the code, you know that there is no '0', and therefore you'd expect the search to return false. But let's see what actually happens.

Code

$values = array("apple","orange","pear","grape");
var_dump(in_array(0, $values));

Output

bool(true)

This result is unexpected and it doesn't make any sense at a first glance. Why would PHP inform us, incorrectly, that there is a zero in the array? To understand what's going on you have to take a look at how PHP compares values.

Type Comparison Basics

What the in_array function does is compare the supplied value with every value in the array until it either finds a matching value (and returns true), or until all the values are compared without a match (and returns false). But, there is a problem. We have passed an integer to PHP and the $values array contains strings. Think of this analogy: comparing strings to integers would be like saying "The sky is exactly as blue as happiness", which makes no sense at all.

So, in order to compare it, PHP has to convert the data to the same type. When comparing strings and integers, PHP will always attempt to convert the string to an integer. Being able to compare strings to integers is a very convenient feature when you deal with user input, especially for beginners who aren't as familiar with data types. Imagine a form that allows you to record how many bottles of water you drank throughout the day. A user can simply type the string '2 bottles' into the input field, and PHP would automatically extract the integer '2' from the beginning of the string.

Code

var_dump("2 bottles" == 2);

Output

bool(true)

The == part is the operator that is being used for a loose comparison. We'll come to that in a minute. Comparing strings to numbers like that makes coding a lot easier, especially for beginners, but it also leads to the mysterious in_array behaviour. It's still hard to understand why passing '0' to in_array in the above scenario will lead to a match. It turns out that the reason is actually quite simple – and sometimes even exploitable – as we'll see later.

The in_array function will compare each array element to the input (and return true) once there is a match. You could write it as the following PHP code:

Code

$values = array("apple","orange","pear","grape");
$input = 0;
foreach($values as $value)
{
        if($input == $value)
        {
                die($value . ' matched');
        }
}

Output

apple matched

The reason why "apple" matches '0' is that PHP tries to convert "apple" to an integer. As seen before in the example with five bottles, PHP tries to extract a number from the beginning of the string, converts it to an integer, and then compares this to the integer we passed for comparison. But, since there are no (zero) leading numbers in "apple", PHP will treat the string as 0. After conversion, the comparison looks like this to PHP:

if(0 == 0)

This kind of behaviour is called an implicit type conversion or 'type juggling'. If you want to have an exact comparison of two values, this may lead to the undesirable results we've seen with in_array.

So what is the solution to this problem?

If we go back to the in_array function, there is an optional third parameter, which is set to false by default:

bool in_array ( mixed $needle , array $haystack [, bool $strict = FALSE ] )

The name of the parameter is $strict, and when it is set to 'true', PHP will take the datatype of the values into consideration when comparing them. This means that even if there is a string beginning with (or solely consisting of) '0', it will still fail the comparison when the other value is the integer '0'.

Code

$values = array("apple","orange","pear","grape");
var_dump(in_array(0, $values, true));

Output

bool(false)

The following table gives a good overview of the behavior of PHP with loose type comparisons.

Loose Comparison Vulnerabilities in PHP

There are various, subtle vulnerabilities that can arise from loose comparison. This section contains an explanation of some of the more common ones.

Authentication Bypass

It would be easy to assume that this code could be used to bypass authentication:

if($_POST['password'] == "secretpass")

Just passing password=0 in the POST body should be enough to fool PHP, and convert the secret passphrase to '0'. However, there is a problem. Array elements in $_GET, $_POST or $_COOKIE are always either strings or arrays, never integers. This means that we would compare the string "0" to the string "secretpass". Since both are already of the same type, PHP does not need to convert anything, and therefore the comparison will result in false. (There are special cases where PHP will still convert strings to integers, but we will talk about this in the next section.)

There are still several problems with this check. When you use parameters that come from json_decode() or unserialize(), it's possible to specify whether you want to pass your number as an integer or a string. Therefore, this would pass the check:

Input:

{"password": 0}

Code:

$input = json_decode(file_get_contents('php://input'));
if($input->password == "secretpass");

Instead of 0, you can even pass true, as ("any_string" == true) will always succeed. The same would work when comparing CSRF tokens.

Reduction in Entropy

A common way to ensure that a value isn't tampered with is using a keyed-hash message authentication code (also known as HMAC) on the server side. An HMAC is the result of hashing operations that contain a secret string and a message. It will be appended to the message that's being sent to the server, and is used as a signature.

An HMAC is often used as an additional security measure when deserializing input, for example, from cookies, since the dangerous unserialize function can only be called if the message was not tampered with by an unauthorized party. In this scenario, the secret string that's needed to generate the signature is only known to the server, but not to the user or an attacker.

Often these signatures are generated as illustrated in the PHP code, even though this does not conform to the RFC 2104's recommended way to create HMACs. This approach has various disadvantages, including being vulnerable to a length extension attack, and therefore should not be used in production in any form. Instead, developers should use PHP's built-in hash_hmac function to generate this kind of signature:

$secret = 'secure_random_secret_value';
$hmac = md5($secret . $_POST['message']);
if($hmac == $_POST['hmac'])
        shell_exec($_POST['message']);

The general idea behind this is that shell_exec will only succeed if the attacker knows the secret value. I have mentioned a special case in the Authentication Bypass section where two strings are converted to an integer when using loose comparison. This one happens when using scientific E-notation. The theory behind this is as follows. Scientific E-notation is used to write very long numbers in a short form. The number 1,000,000, for example, would be written as '1e6'. In other words 1*(106) or 1*(10*10*10*10*10*10) or 1*(1000000). This is problematic because usually hashes, like md5 in our example, are written in hexadecimal encoding, which consists of the numbers 0-9 and the letters a-f.

After enough attempts, you can therefore generate a string that begins with '0e' and is followed by numbers only. In most cases, this is significantly easier than bruteforcing the secret value. The reason why this is the desired format is that '0*10n' is always '0'. So it doesn't really matter which numbers follow after '0e', it will always result in the number '0'. That means we can add random characters to our message and always pass the signature '0e123' to the server. Eventually the message hashed with the secret value will result in the format ^0e\d+$, and PHP will convert both strings to '0' and pass the check. This can therefore significantly reduce the number of attempts that an attacker needs to bruteforce a valid signature.

Code

var_dump("0e123" == "0e51217526859264863");

Output

bool(true)

Of course, this is also a problem in databases with lots of users. Using this format, an attacker can try to log into every single user account with a password that will result in a hash of the mentioned format. If there is a hash with the same format in the database, he will be logged in as the user that the hash belongs to, without needing to know the password.

Hashing Algorithm Disclosure

It's also possible to check whether or not a specific hashing algorithm is present when loose comparison is used, similar to the Collision Based Hashing Algorithm Disclosure. In this case, a tester has to register with a password that results in a hash, in the scientific E-notation format. If he is able to log in with a different password that also results in a hash with the same format, he knows that the site uses loose comparison and the respective hashing algorithm. For MD5, the strings '240610708' and 'QNKCDZO' can be used:

Code

var_dump(md5('240610708') == md5('QNKCDZO'));

Output

bool(true)

Fixing Type Juggling Vulnerabilities in PHP Web Applications

It's relatively easy to fix Type Juggling vulnerabilities – most of the time. In cases of simple comparisons, we recommend that you use three equals symbols (===) instead of two (==). The same goes for !=, which should be avoided in favor of !==. This makes sure that the type is taken into consideration when comparing the values.

It's also advisable to consult the PHP manual to see which functions compare loosely, and whether they have a parameter to enforce strict comparisons.

And, you should avoid writing code like the following:

if($value) {
        //code
}

Instead specify the desired outcome like so, to be safe:

if($value === true) {
        //code
}

For strict comparisons, the table now looks like the one below, representing more sane and predictable behaviour than that represented in the table at the beginning of this blog post.

Finally, we recommend that you avoid casting the strings to the same type, before comparing them, as this often has the same effect as the == operator.

Code:

var_dump((int) "1abc" === (int) "1xyz");

Output:

bool(true)

The PHP developers have made the decision to sacrifice security for convenience and ease of use. Even though this approach allows inexperienced users to code a website in PHP, it makes it much harder for them to keep it secure. Additionally it creates unnecessary pitfalls into which even experienced developers might stumble if they are not careful enough.

Google released Chrome version 68 in late July 2018, marking the start of a new era for secure web browsing. From version 68 onwards, all websites using HTTP will be marked as Not Secure on Chrome browsers. Starting with Chrome 69, we will no longer see the green lock icon on HTTPS websites, as secure connections will be considered the de facto standard.

Chrome marks a website secure by checking the validity of a TLS certificate on the website. But this isn’t the only proactive stance adopted by Google when it comes to promoting Transport Layer Security (TLS). Here are some of the changes Google introduced in recent years, that encourage administrators to take TLS seriously:

• They made HTTPS a factor in the search engine results ranking
• They implemented Public Key Pinning technology in their browsers
• They invented and implemented the HSTS Preload List
• They strictly regulated Certificate Transparency and the use of the Expect-CT header

In a previous Weekly Security Roundups, we mentioned a few of the threats that arise with the lack of a proper implementation of an SSL/TLS certificate and how you can avoid them. Let's take a fresh look at these threats in light of the new, major security updates.

Why Should We Use SSL/TLS?

SSL/TLS lays the foundations of integrity, privacy, and authorization by providing end-to-end encryption. An ideal Secure Sockets Layer (SSL) implementation ensures the safety of all online data transfers between users and websites, preventing attackers from reading or modifying the information. SSL also helps to authenticate the two systems that are communicating with one another.

In summary, an intervening third party cannot read or modify the web traffic when a correct SSL/TLS implementation has been configured.

Can a Third Party Intercept Our Data?

The data we send and receive on the internet goes through sometimes hundreds of hops,  intermediate switches, servers and fiber optic cables before it finally reaches its destination. If any of these intermediate destinations are intercepted by an attacker and lack encryption, the packets we transmit are susceptible to being read and modified. An attack that involves a third machine interpolating between two genuine, communicating endpoints is called a Man in The Middle (MiTM) attack.

The term 'integrity' is used to describe the assurance that the data transferred between two systems is not modified by any unauthorized third party. SSL/TLS allows encrypted data transfers, but the intercepting party can trick one endpoint into establishing the encrypted connection with it, instead of the intended recipient. Therefore the validation and authorization of the recipient is highly crucial too. Modern browsers take care of this responsibility. All the administrator needs to do is to set up HTTPS with a valid certificate and follow a few additional steps to ensure a proper implementation of TLS. Let’s guide you through these steps.

Encryption Keys and SSL/TLS Certificates

SSL/TLS technology uses public key infrastructure (PKI) which requires you to own a pair of keys which will include a private key and a public key. You can share the public key with all parties who want to contact you over an encrypted channel. The encrypted packets will be decrypted with your private key.

The method in which a plaintext is encrypted and decrypted using the same key is called Symmetric Encryption. How it works is that the sender and the receiver use the same key to encode plaintext and decode ciphertext as shown. However, due to the possibility of the cipher key being stolen, this method may only prove useful if a single user will encrypt their personal files and guard the key from unsafe parties.

The biggest benefit of PKI is that it overcomes the risk in such symmetric-key algorithms. Those who want to have an encrypted connection using PKI must have the recipient's public key.

If we were to adopt this approach to websites, we’d have to handle the keys for millions of users. A visitor might surf hundreds of web pages in a session, so holding the public key for every website is impossible. To ease this process, websites have to publish their public keys before establishing a secure connection.

The Role of Certificate Authorities

The identity of these websites can be verified and confirmed by Certificate Authorities (CA). The CAs are recognized and trusted by all browsers. Instead of storing every public key on the browser cache, browsers trust the CAs to verify public keys.

SSL certificates are documents acquired from trusted certificate authorities that record the website’s public key. When a user demands secure communication with this website, the website presents this certificate. The browsers verify the signature of a trusted CA on the certificate, and then process the request if it’s successfully verified. However, if the CA is not trusted or a misuse is detected, the browsers take actions based on the configurations made by the website owner, varying from reporting to ending the session.

Where Can You Acquire a Certificate for Your Website?

You can get an SSL certificate for your website from many sources. We recommend and sponsor Let's Encrypt which is available for free.

Steps After Acquiring a Certificate

Owning a certificate is only the first step in establishing a secure connection. Let's take a look at the additional steps you should take after acquiring a valid certificate.

HTTP Strict Transport Security (HSTS): a Must for Secure Connections

If you want to take full advantage of SSL, you have to convert all HTTP requests to HTTPS in addition to loading all images, scripts, style files and others over a secure connection. When it comes to certificate errors, you have to go as far as blocking the user from discarding the error to ensure security. But, doing all this manually is rather difficult, especially in the case of a certificate error when you have to bar the user from accessing your website.

The HSTS specification published on November 2012 rescues us at this point. All we have to do is to send a security header (Strict-Transport-Security) on our web page response.

For further information, see the whitepaper HTTP Security Headers and How They Work.

HSTS Preload List

We can only set the HSTS header over a secure connection. Just like Public Key Pinning, which uses another HTTPS security header, HSTS is based on Trust on First Use (TOFU). This means we’ll have to manually redirect the users on their first HTTP request to the HTTPS version of our website. In its response, there will be an HSTS header, which browsers will store in their cache. The next time an unsafe (HTTP) connection is detected, the user will automatically be redirected to a secure connection.

The obvious question is, can't this first HTTP request be overridden with a MiTM attack? Unfortunately the answer is: Yes.

This is where the HSTS Preload List comes in.

HTTP Public Key Pinning (HPKP), Certificate Transparency, Expect-CT and CA

How does the browser control the certificate of the website as part of a secure connection?

It does so by checking whether the certificate is signed by a trusted authority.

However, several recent incidents showed that regardless of the motive, one of these certificate authorities can sign a certificate on behalf of a website without notifying the website owner. Technically, CAs aren’t required to notify the website owners or need identity verification documents to sign a certificate, even though the website owners have to submit various documents in their request.

An example of this occured in the Netherlands in 2011 when the authorized certificate distributer DigiNotar was hacked and around 500 certificates were fraudulently signed. Multiple Google services including 300,000 Gmail accounts of Iranian citizens were monitored with the help of these certificates.

A similar incident took place in the years 2008 and 2011, affecting a Certificate Authority called StartCom. Certificates for paypal.com and verisign.com were published. In 2011, attackers accessed the root key of StartCom, and acquired the ability to produce, invalidate, or renew certificates.

To prevent this threat, we recommend that you use HPKP, Certificate Transparency, Expect-CT, or CAA Entry.

For further information, see HTTP Security Headers and How They Work.

The Importance of Subresource Integrity (SRI) and Content-Security-Policy (CSP)

HTTPS ensures secure data transfer. This means that if the files we receive are transferred over a secure protocol, they will maintain their integrity and security until they reach us.

What if the servers that host these files are attacked and the script and style sources are modified?

HTTPS will not be able to prevent this, and it won’t be able to maintain website security. Subresource Integrity (SRI) is the feature to aid us in such incidents.

Since the release of its first version in November 2012, CSP has been acting as an additional client-side security layer against various vulnerabilities like cross-site scripting, clickjacking, protocol downgrading, and frame injection. For further information, see Content Security Policy.

Protocol Downgrading is when an HTTPS connection is ‘downgraded’ into HTTP. This happens when a developer forgets to upgrade the HTTP links when the entire website is converted to HTTPS. Or, on pages where dynamic content is loaded, requests to load resources over HTTP might still exist.

Relative Schema

You can use Relative Schema in resource loading or href attributes to enforce the scheme used in accessing the website (hopefully SSL/TLS at this point) on all URLs found in src and href attributes.

For example, if our website is https://www.example.com, the image source will be retrieved over a secure connection too:

<img src="https://www.netsparker.com//www.anotherdomain.com/dog.gif"/>

Since our website is HTTPS, all domains set using relative schema in image source will be converted to the HTTPS scheme.

SSL/TLS Implemented Everywhere

You can implement SSL/TLS on all connections using HSTS, CSP, and Relative Schema as stated above.

Why do you need SSL on pages other than the checkout and login pages?

You might not find it odd to see http://www.example.com/js/jquery.js  is loaded over an (insecure) HTTP connection while https://www.example.com/checkout.php is loaded over HTTPS.

However, an attacker might intercept the connection and inject the following code in jquery.js and gain access to all actions and inputs on checkout.php. The code below is the real source code of a Javascript malware.

// Only run on pages with worthwhile info
if ((new RegExp("onepage|checkout|onestep", "gi")).test(window.location)) {
 Malware.send();
}

If the page contains the words 'checkout', 'onepage', or 'onestep', the code above will be injected.

Should I Implement SSL/TLS on my Static Website?

Yes. Since the injected malicious code will be executed and bring negative results on the end-user’s browser, your website’s static or dynamic type won’t matter.

Even if it is static, a user attempting to access your webpage might be greeted by an injected Flash Player update prompting them to download and launch malicious software.

Troy Hunt prepared a video to demonstrate the necessity of SSL on static websites. Click here to watch his presentation.

Secure Your Connections for a Better Future

With the normalization of HTTPS, secure connections are becoming the default access protocol on the web. Having a secure connection is crucial to every aspect of the web, from your ranking in search engine results to your institution’s reputation. We’re hoping the points we’ve shared on SSL/TLS implementation have been enlightening and convincing enough for you to take definite action on securing the connections of your website.

Authors

Ziyahan Albeniz
Sven Morgenroth
Umran Yildirimkaya

Confusion between the terms 'penetration testing' and 'vulnerability assessments' often begins at the level of language. Those who are not full-time professionals in web security, such as journalists reporting on a big story that affects consumers, use the terms interchangeably, as if referring to the same process.

Experienced professionals in the industry know the difference, but those new to it can be easily confused. Why? Even professionals sometimes use terms in fuzzy or inexact ways, when they should distinguish between things that differ. Let's be clear on the difference between the two.

What Are Vulnerability Assessments?

A vulnerability assessment involves running a series of multiple tests, against defined websites, web applications, IP addresses and ranges, using a known list of vulnerabilities, such as the OWASP Top 10 list. Assessors may also run tests against systems they know to be incorrectly configured or unpatched. Often, automated security scanning tools are used. Commercially licensed, subscription-based tools are regarded as coming with less risk – regular updates, release notes bring less chance of the inclusion of malicious code. (Their open source equivalents, however, have the significant advantage of being the exact same tools that malicious hackers prefer.)

Vulnerability assessments tend to include the following stages:

• Identifying all resources, and connected resources, within an organisation's IT systems
• Assigning a value or priority to each one
• Conducting an assessment of lists of known vulnerabilities across a large number of attack surfaces (from login screens to URL parameters to mail servers)
• Fixing the most critical vulnerabilities and making decisions about how to the deal with the rest

What is Penetration Testing?

Penetration testing (pen testing), on the other hand – while it may be considered to be a type of vulnerability assessment – involves replicating a specific type of attack that might be carried out by a hacker. A pen tester will often explore the systems until they find a vulnerability. They may even employ a vulnerability assessment tool to uncover a vulnerability. Once they find something, they will then try to exploit it, to determine whether it would be possible for a hacker to achieve a certain objective (access, change or delete data, for example). Often, while doing this, they may accidentally encounter other vulnerabilities, and follow where they lead. The pen tester may use an automated tool at this point to run a series of exploits against the vulnerability.

Some penetration tests are referred to as 'white box' to indicate that the penetration tester has been given detailed information about the environment, such as a list of assets belonging to the organization, source codes, employee names and email addresses etc. When they are referred to as 'black box', this indicates tests that are conducted without any prior information about the internal structure, access to source code etc.  This kind of pen test of course, can more closely resemble the activities of a malicious hacker, but may also lead to less thorough coverage of the companies potentially vulnerable assets.

What Results Can I Expect From Each Approach?

The answer to this question might best be asked by thinking backwards: What results do you want?

Vulnerability Assessments Report Across All Vulnerabilities

The results are collated in an automated, lengthy report, with a comprehensive list of detected vulnerabilities arranged by priority, determined by how by severe and business-critical they are. As time goes on, this list can reveal changes since the last report. One of the criticisms of the results achieved is that, unlike in penetration testing, they can contain false positives or false negatives. Naturally, this is not the case if you use Netsparker web application vulnerability scanner to conduct your vulnerability testing. It is one of our key features – automatically verifying identified vulnerabilities with Proof-Based Scanning™.

Reports should include guidance on how to remediate the detected vulnerabilities, and tools sometimes come with patches subscribers can use. In most cases, results are then allocated to dedicated development teams who conduct fixes, remove the most serious vulnerabilities, and otherwise address the less serious ones. In an ideal world, this activity is ongoing, scheduled regularly, and built into the organisation's SDLC.

Penetration Testing Reports Deep Into Each Vulnerability

With pen testing, there is no lengthy public report, though some record and publish their actions and anonymized findings, blog about their experiments, or live hack at conferences. If you hire a pen tester, however, they should deliver a (pen test) report, but it tends to be focused on the attack method or exploit, and exactly what data can be compromised. It will generally be accompanied by suggestions on what a hacker might be able to do to, or with, it. This helps business analysts and non-technical professionals, who may not understand all of the technology behind such tests, grasp business process impacts quickly.

Sometimes reports also incorporate remediation advice. However, not all pen tests incorporate exploitation of vulnerabilities in the way that Netsparker does. It may be sufficient simply to illustrate that an attack is possible. In some cases the pen test report may simply report theoretical vulnerabilities because attempting to exploit them may result in a catastrophic denial of service (DoS). And, finally, there is no assessment of vulnerabilities, since the goal is simply to do one thing, or least to determine whether it can be done.

Which Approach Should My Organisation Adopt?

The main question to ask is: What is your current security posture?

Vulnerability Assessment Builds Security Continuous Improvement Into your Enterprise SDLC

Vulnerability assessments are a highly systemised way for established organisations to gain a comprehensive picture of their security posture, and then maintain and continuously improve on it. When new devices, ports, websites, web applications, or services are added, they are included in regular scans. A vulnerability assessment is a great way to identify, and eventually fix, common vulnerabilities in your applications and servers.

Most security professionals recommend that vulnerability testing is conducted at least quarterly. Our recommendation, however, given that Netsparker allows you to configure scheduled scans, is to scan much more frequently. In any case, you should conduct vulnerability tests following any significant change or addition to your web applications or web APIs. With Netsparker, if you want to, you can run scans daily, with notifications drawing your attention to detected vulnerabilities as they arise. Resources can then be deployed rapidly to deal with critical and important threats.

Penetration Testing Exposes Fragile Cracks In Your Security Architecture

Since penetration testing is so specific, it is best suited to environments where an organisation's web and network security is considered to be already robust. Organisations may ask a tester to attempt to do something specific, such as gain access to a transactions or bank details database, or alter or delete a single record. The purpose is to reduce exposure to certain risks. Penetration testers check for weak points in the architecture. While vulnerability assessments mostly take care of software vulnerabilities, penetration testers may often use phishing, social engineering and onsite engagements in order to reach their goal. Therefore they can give a much more accurate depiction of a company's security level. They act exactly as malicious hackers, without producing any devastating loss or alteration of data, of course! For example, a penetration tester might try to establish a connection to a remote server without being detected, in order to exfiltrate sensible data from a system. It is a useful way to demonstrate if attackers with particular objectives in mind stand a healthy chance of success. Ostensibly, though, a pen tester would conduct an endless series of attempted hacks.

The recommendation is that penetration testing is conducted at least once per year.

What Scenarios Can Help Determine the Choice of Approach?

Both vulnerability assessments and penetration tests should be run against network devices, and internal and external servers. It's crucial to determine whether an attack is possible from the outside (for example, by a malicious attacker targeting publicly-available target surfaces on the internet) or the inside (for example, by a disgruntled employee or contractor, a user with permissions they should not have, or a compromised machine within the internal network).

Vulnerability Assessments Help Enterprises Maintain Consistent Compliance With Standards

Sometimes organisations need to work within certain parameters: they have PCI DSS or other forms of compliance to adhere to and want to test if the current architecture, systems and devices would pass the test. They may want to run a port scan or check against everything on the OWASP Top 10 List. In such scenarios, a vulnerability assessment will provide a more realistic and systematic approach. Even a very large team of developers could never comprehensively reach the end of such tests.

Penetration Testing Helps All Organisations Keep Ahead of the Hackers

Penetration testing comes at security from a different angle. Testers will uncover security risks in the same way that hackers do – by conducting attacks with a single purpose in mind, to gain access to certain data or to change something on an organisation's website, for example. Pen testers are best commissioned with an open mind, leaving them free to conduct both requested attacks and anything else that occurs to them, depending on their professional experience.

What About the Testers?

One of the most important questions to consider, to help distinguish between vulnerability assessment and pen testing, is: Who's conducting the testing?

Information Security Professionals Establish Internal Procedures for Continuous Improvement

Contrary to some articles on the subject, vulnerability testing is not a fully-automated process in the sense that all it takes is to push a button. The person who manages regular, automated vulnerability assessments must be already skilled and experienced in information security procedures. They must know what environments and attack surfaces to assess and what to assess them for, as automated security scanners will still require some configuration. And they must be able to interpret the resulting reports and make recommendations on what needs to be done next.

In-house security professionals responsible for vulnerability assessment continuously add value to the security status of organisations and their resources. First, they can establish a baseline. They are likely to want to establish some systems, particularly an assessment schedule and reporting. They can help raise awareness within, while facilitating a continuous reduction in security risks. Meanwhile, they will most certainly expand their own knowledge and skills. Arguably, they are much more likely to feel loyal to an organisation in which they already work.

Penetration Testers Tell It Like It Is

Penetration testers, likewise, must also be knowledgeable professionals who are confident in their abilities.

Most professionals in the field recommend that penetration testers should be independent, external professionals. They must maintain enough distance from your company or systems that they are not hampered by concerns about personal financial security, loyalty or politics. This enables then to state the blunt truth about your security status, however much it hurts!

What About Cost?

How much vulnerability testing costs depends on the scope of the engagement. For small organizations the price will be significantly lower than for a big corporation with thousands of potentially vulnerable machines, IPs and internet facing hosts.

Regardless of the cost, vulnerability assessments produce a better yield on investment. While a pen test may be a deep slice of how secure your system is, it only reveals one thing in one direction. Vulnerability assessments take the long view, investing time and resources in developing systems and procedures that will yield a solid level of security on which to further develop your systems and integrate new components.

So, Which Approach Do We Select?

Simply put, do both. Both approaches have the capability to uncover gaping holes in your security and reveal other less obvious vulnerabilities, ones you weren't even looking for. One thing is certain, if you're not scanning or testing, you will encounter a loss of data. The only question is when. Whether it's a known vulnerability that you've not addressed, or the result of a bored hacker's Sunday afternoon adventures (yes, it's true, they're not all malicious!), the result is the same.

The mature, preventative approach is to establish vulnerability testing and scanning as part of your regular SDLC, and additionally employ some unusual types to do what a hacker might do, but on friendly terms ('white box' pen testing). Then you can read all the reports and results, examine the recommendations and make smart decisions on how to keep your organisation's security posture ahead of the bad guys.

Netsparker is sponsoring and exhibiting at OWASP AppSec USA 2018. The conference exhibit will take place from October 11th until the 12th at the Fairmont San Jose.

Join Us at the Diamond Sponsor Booth at OWASP AppSec USA 2018

If you are attending OWASP AppSec USA, stop by our Diamond Sponsor booth. Our team will be happy to talk to you and answer any questions you might have about automated vulnerability scanning and scaling up web application security.

For more information about the conference, visit the official OWASP AppSec USA 2018 website.

We look forward to seeing you there!

Watch episode 572 of Paul's Security Weekly, during which one of our Security Researchers, Sven Morgenroth examines data types and PHP Type Juggling Vulnerabilities.

During the show, hosted by Paul Asdoorian, Sven explains:

• Sometimes when you have different data, you need to compare it. Sven kicked off his presentation by looking at data types in PHP. This is easy when the two pieces of data are of the same type. However, Sven gave an example of what happens if they are not. In his example, in the case of strings and integers, PHP can convert a string to an integer by extracting a number at the beginning of the string. However, even when strings don't contain numbers, Sven demonstrated that PHP still wants to convert it to an integer and so returns weird values, such as zero.
• At this point, Sven jokes that even Paul may get lost from this point onwards! And, he displays a self-produced type chart of potential PHP Type comparisons whose results look very confusing. For example, an empty array returns 'false', whereas an empty object returns 'true'.
• The important question Sven poses, though, is: While PHP's loose comparisons comparisons might be strange, is PHP actually insecure? His first point was simply that programming languages should be predictable – obviously and especially in a security-critical context. And, comparisons cannot be avoided; they are everywhere. He goes on to list the serious security vulnerabilities arising from this 'Type Juggling', including Authentication Bypasses, crypto-related flaws and Hashing Algorithm Disclosure, and provides a few examples of each one. You can read an example of an Authentication Bypass in CMS Made Simple.
• Following Sven's vulnerability demos, they discussed the double equals and triple equals syntax, and Paul noted how this was a great example of how PHP "is very insecure right out of the box". They concluded, though, that PHP developers were surely aware of this and were simply trying to make it easier to write (not necessarily accurate) code, and that other languages probably had similar examples, particularly JavaScript.

A Report Policy in Netsparker is a list of reporting settings for both the web security scan results and reports. A Custom Report Policy, therefore, enables you to configure these settings – how the web security scanner reports its findings in the interface and in reports. (If you want to enable or disable specific security checks in the actual Scan itself, you should configure a Scan Policy instead.)

When you exclude the SQL Injection vulnerability from a Report Policy and run a report, the scanner will still check if the target web application is vulnerable to this vulnerability. However, if it detects one, it won’t report it in the Scan Results. With the Report Policy, the SQL Injection is only hidden.

If you later generate a Report from the same Scan with the Default Report Policy, in which the SQL Injection vulnerability is included, the identified SQL Injection vulnerability will be listed in the report.

For example:

• You can specify which detected vulnerabilities Netsparker should report in the Scan Results
• You can also change the Severity level – or the visibility – of a vulnerability

Creating a Custom Report Policy

Netsparker Cloud's built-in Report Policy is called Default Report Policy. It is read-only and it is used to provide the default settings for your custom Report Policies. You can clone existing Report Policies or create new ones, and then the new custom report policy modified to suit your requirements.

Two significant customisations are possible:

• Excluding a vulnerability from the web security Scan Report
• Changing the Severity Level of a vulnerability

Each is explained in Report Policy Fields below.

Report Policy Fields

This table lists and explains the fields in the New Report Policy window and how to exclude a vulnerability or how to change the severity level of a vulnerability.

How to View Report Policies

From the main menu, click Policies, then Report Policies. The Report Policies window is displayed. From there, you can view, clone, edit or delete any listed policy.

How to Create a Custom Report Policy

1. From the main menu, click Policies, then New Report Policy. The New Report Policy window opens at the General tab.

2. In the Name field, enter a name for your report policy.
3. In the Description field, enter a description for your report policy.
4. Click the Vulnerabilities tab. The full list of vulnerabilities Netsparker scans for is displayed.

5. Browse through the list of vulnerabilities and use the checkboxes to select or deselect the ones you want to include or exclude from your Scan Report. You can also use the input field at the top to search for a specific vulnerability.
6. For reach vulnerability, use the dropdowns in the Severity column to change the Severity Level of each vulnerability, if required.
7. Click Save.

How to Clone the Default Report Policy

1. From the main menu, click Policies, then Report Policies.
2. For the relevant policy, click Clone.
3. Complete the fields as described from step 2 in How to Create a Custom Report Policy.

Using a Custom Report Policy

Once you have created a Custom Report Policy, you can use it when creating a New Scan, New Scheduled Scan or New Group Scan.

How to Use a Custom Report Policy in a Scan

1. From the main menu, click Scans, the New Scan. The New Scan window opens at the General tab.

2. From the Report Policy dropdown, select your Custom Report Policy.
3. Complete the remaining fields as described in Security Scans.

Integrating Netsparker Cloud with Slack

Slack is a team messaging system that enables enterprise teams to communicate across a series of dedicated project or department channels via messaging and calls.

How to Configure Netsparker Cloud for Slack Integration

1. Go to the Slack Button documentation and scroll down to the Register your Slack app section.

2. Click Create your Slack app.

3. In the App Name field, enter an app name.
4. From the Development Slack Workspace dropdown, select a workspace. (If you are not currently signed in to the Slack workspace you want to integrate, select Sign in to another workspace from the dropdown.)
5. In your Slack app, in the Basic Information page, copy your Client ID and your Client Secret. (You will need them in a later step.)

6. In Netsparker Cloud, from the main menu, click Integrations then, New Integration.
7. In the Team Messaging Systems section, click Integrate Slack and paste the details you copied in a previous step into the Client ID and Client Secret fields. Changing Client ID and Client Secret fields won’t affect existing Slack Integrations.

8. In the same window, copy your Slack Redirect URL.
9. In the Slack app, in the OAuth & Permissions window, paste in your Redirect URL, and click Save URLs.

How to Integrate Netsparker Cloud with Slack

1. From the main menu, click Integrations, then New Integration.

2. In the Team Messaging Systems section, click Integrate Slack. The Slack Integration Settings page is displayed.
3. Click Integrate.

4. You are redirected to the Slack authorization page.

5. Click Authorize. Once you authorize Netsparker Cloud on the selected channel, your integration will be configured. You can view this in the Integrations window.

6. In the Issues window, you can send selected issues to the newly-configured Slack channel by clicking Send To and selecting the Slack integration from the dropdown.

Managing Integrations

For further information on how to view and manage Integrations, open How to Integrate Netsparker Cloud with an Issue Tracking System and scroll down to Manage Integration. Both types of Integration can viewed and managed in the same place.

Configuring a Notification to Report Vulnerabilities to Slack

For further information on how to configure a Notification to report vulnerabilities to an issue tracking system, open How to Integrate Netsparker Cloud with an Issue Tracking System and scroll down to Configuring a Notification to Report Vulnerabilities to an Issue Tracking System. Notifications for both types of Integrations can configured in the same place.

Viewing Notifications While Creating a New Scan

For further information on how to view Notifications while creating a New Scan, open How to Integrate Netsparker Cloud with an Issue Tracking System and scroll down to Viewing Notifications While Creating a Scan. Notifications for both types of integrations can be viewed in the same way.

In our example, if any Critical, Important or Medium severity vulnerabilities are found during a scan, they will be recreated in the newly-created integration (#nc-slack-test)'.

We're delighted to announce a Netsparker Desktop 5.1 update. The highlights of this update are a new Bulk Export to Cloud feature, Send To integration support for ServiceNow and custom field support for Send To fields.

This announcement highlights what is new and improved in this latest update.

Bulk Export to Cloud Feature

This new feature enables you to bulk export scans conducted in Netsparker Desktop into your Netsparker Cloud account. It's as simple as navigating to File>Export to Cloud>Bulk Export.

This offers better interoperability between our products.

Send To Integration Support for ServiceNow

ServiceNow is a recent integration available in Netsparker Cloud. You can now configure ServiceNow in Netsparker Desktop from the Options dialog (Home>Options>Extensions>Add).

Custom Field Support for Send To Fields

You can now create custom fields in the Options dialog, in addition to the built-in fields, to facilitate the systems that have customized fields. These fields will be populated when a vulnerability is sent.

This new feature makes it possible to integrate with even more issue tracking systems.

New Security Checks

We have added several new security checks to our Default Security Checks list in Scan Policies:

• Out of Band Server Side Template Injection
• Checks for the open source CakePHP framework

For further information, see Scan Policies and our full list of Security Checks in our Web Application Vulnerabilities Index.

Further Information

For a complete list of what is new, improved and fixed in this update, refer to the Netsparker Cloud changelog and Netsparker Desktop changelog.

We are excited to announce our sponsorship of the B-Sides DC 2018 Conference in Washington, D.C, which takes place from October 26th until the 28th.

During the conference we will exhibit Netsparker, our market leading web application security scanner.

B-Sides DC is a community-driven event developed by and for information security practitioners who seek to expand the spectrum of conversations and create opportunities, in an intimate atmosphere that encourages collaboration.

The venue for B-Sides DC is the Renaissance Washington DC Downtown Hotel.

For more information, visit the B-Sides DC website where you can find out more about the event and how to support it.

Join Us at Our Booth while at B-Sides DC 2018

If you are attending B-Sides DC, then come and visit us at our booth. We will be more than happy to answer any questions you might have about web application vulnerability scanning and Netsparker.

We're delighted to announce a Netsparker Enterprise update. The highlights of this update are integration with ServiceNow and Slack, a new Report Policy Editor, and Security Check updates similar to those just released in Netsparker Standard 5.1.

This announcement highlights what is new and improved in this latest update.

Integration with ServiceNow

ServiceNow is an issue tracking system used by corporations to manage projects, tasks and teams. ServiceNow integration is now available in Netsparker Cloud.

For further information, see How to Integrate Netsparker Cloud with an Issue Tracking System.

Integration with Slack

Slack is a team messaging system that enables enterprise teams to communicate across a series of dedicated project or department channels via messaging and calls.

For further information, see How to Integrate Netsparker Cloud with Slack.

Report Policy Editor

We created a Report Policy Editor which enables you to customize your Scan Report results.

For further information, see Working with Custom Report Policies.

New Security Checks

We have added several new security checks to our Default Security Checks list in Scan Policies:

• Out of Band Server Side Template Injection
• Checks for the open source CakePHP framework

For further information, see Scan Policies and our full list of Security Checks in our Web Application Vulnerabilities Index.

Further Information

For a complete list of what is new, improved and fixed in this update, refer to the Netsparker Cloud changelog and Netsparker Desktop changelog.