Low-code software builders will take off your hands most boring and repetitive tasks, which includes the security of your web application. Apps, created by PHPRunner and ASPRunner.NET follow all the security standards and secure out of the box. Your projects will be protected from SQL injection, XSS, CSRF, and more. If you’d like to know more about the most common web application vulnerabilities check OWASP Top Ten Security Risks. In this article, we will discuss additional security measures that are not directly related to the generated code but nevertheless are extremely important. If you ever need to build a public web application you need to go through this checklist and make sure your application complies.

1. Location of file-based database

If you use a file-based database like MS Access ( you should not ), make sure that the database file is not accessible directly via the internet. The best option is to place it outside of the website root folder. Otherwise, an attacker can eventually guess the location and name of your database and download it.

2. Location of uploaded files folder

The same applies to uploaded files, the best option is to use a folder, that is not directly accessible via the internet. In PHPRunner and ASPRunner.NET for this purpose, we use the ‘Absolute path’ option while specifying the path to the upload folder.

If you must to use upload folder that is accessible via HTTP make sure that you prohibit scripts execution in that folder. For this purpose, in IIS create web.config file with the following content:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <handlers accessPolicy="Read" />
    </system.webServer>
</configuration>

And the same directive for .htaccess file ( Linux + Apache ):

<Directory "C:/xampp/htdocs/(path_to_directory)/dirname">
    SetHandler default-handler
    Options None
    AllowOverride None
</Directory>

3. Use HTTPS

This is an extremely common requirement these days, some web browsers won’t even let you open an HTTP website. You can even use free SSL certificates provided by Let’s Encrypt.

4. Use all the latest versions of all server software

If you run your own web server, make sure that all the software is upgraded to the latest versions. This is especially true for any public-facing software like IIS, Apache, PHP and ASP.NET.

5. Password hashing

Turn on password encryption. If your database ever gets compromised, attackers won’t be able to see users’ passwords. This may prevent unauthorized access to other websites if users do not follow the “separate password for each website” practice.

6. Use Two-Factor-Authentication

This is also now a standard for most websites that store any potentially sensitive data. PHPRunner and ASPRunner.NET support 2FA via SMS, email, and apps like Google Authenticator. Enable 2FA in the software and encourage users to enable and use it.

7. Data encryption

Encrypt sensitive data in the database like social security numbers, addresses, birth dates, etc. If hackers ever get access to the database they won’t be able to see the encrypted data, unless they also have access to the encryption key.

Data Encryption is a part of Enterprise Edition of PHPRunner and ASPRunner.NET.

8. Properly configure access permissions in the software

This is kind of obvious but it made OWASP Top Ten list. Make sure that each user and user group only has access to those pages and data that they are allowed to see. For this purpose, in PHPRunner and ASPRunner.NET use User Group Permissions and Advanced Security options like “Users can see and edit their own data only”.

It is important to enable Advanced Security for all tables that end user has access to. For instance, if you use master-details relationships, make sure that you enabled Advanced Security mode for both master and details tables.

9. Turn off detailed error messages

Detailed error messages can reveal important info like file names, table and field names etc. Turning detailed error messages off can be done in IIS settings for ASPRunner.NET and in PHP settings for PHPRunner. Also in the software itself choose to display a generic error message.

10. Prohibit remote access to your database

Make sure that your database is only accessible locally, from your web server. Opening the remote access invites brute force attacks and also increases the load on your database. Setup firewall rules that would prohibit remote connections.

For development purposes, use a local copy of your database.

11. Prevent SQL injection in your own code

While all the core code generated by PHPRunner and ASPRunner.NET is fully protected from the SQL injection, you need to take care of this in the code you add to events. For this purpose, you can use PrepareSQL function that will take care of this.

PHP example:

$sql = DB::PrepareSQL("insert into log (lastname) 
  values (':1')", $values["name"]);
DB::Exec( $sql );

C# example:

sql = DB.PrepareSQL("insert into log (lastid) values (:new.id)");
DB.Exec( sql );

12. Avoid storing sensitive data in your database when possible

For instance, instead of storing credit card info in your own database use a service like Stripe to process credit cards. This way credit card info never touches your server and you do not need to worry about PCI compliance which is a major pain on its own and an overkill for most projects.

13. Database access isolation

Make sure that each database user only has access to required data and operations. If hacker gets access to one web application they won’t be able to use the same database credentials to access other databases.

14. File access isolation

The same idea as with databases. If hacker gets access to a certain we application we need to make sure he cannot access any files outside this application’s folder. Here are instructions for IIS and PHP.

Create a folder named .temp inside this application’s folder. Provide read/write permissions for IUSR user. Deny List permissions. In this folder we will store PHP sessions.

Open this folder in IIS manager and proceed to Handler Mappings. Click Edit Feature Permissions on the right. Clear all checkboxes.

Open main application’s folder in IIS Manager. Double-click on PHP handler and modify the path to PHP executable this way:

C:\PHP80\php-cgi.exe|-d session.save_path="C:\inetpub\wwwroot\website.com\appfolder\.temp" -d open_basedir="C:\inetpub\wwwroot\website.com\appfolder\"

open_basedir directive tells PHP to block access to any files outside this folder. More info on open_basedir.

Adding Web Application Firewall as an extra level of protection

Web Application Firewall (WAF) is software that helps protect web applications by filtering and monitoring HTTP traffic between a web application and the Internet. Examples of popular web firewall software are Fortinet FortiWeb and Sucuri Website Firewall. Personally, we found configuring WAF time-consuming and providing little benefit. It may work well for your application though.

Preventing automated attacks

You do not want hackers to run automated scripts to brute-force your passwords. To prevent this from happening you can use built-in features like ‘Lock user account after three unsuccessful logins’, two-factor authentication and reCAPTCHA.

Testing for vulnerabilities

How to test for vulnerabilities and how to interpret the results? Most companies use a vulnerability scanner to assess their web project’s security. The most known products in this area are Acunetix and HCL AppScan (formerly IBM AppScan). These products will test all the pages of your web application against known vulnerabilities and create a report listing everything they found.

It is important that developers and the team that runs the vulnerability scanner work together to interpret the results properly. Let me give you an example. There is a vulnerability called “blind injection” (there in fact multiple versions of it like blind LDAP inject, blind SQL injection etc). The idea is to send a different set of request parameters to a certain page and your app should not indicate that parameters were and should return exactly the same output. The idea is not to provide any feedback and make parameter guessing more difficult.

One of the customers was running a vulnerability scanner against a PHPRunner app. First, the scanner executes a normal load of the list page. Then it adds a random parameter to that list page call and runs it again. The output was different and the scanner marks it as “critical vulnerability”. Turns out, they ran the vulnerability scanner against a live database that was constantly updated and the difference between the two requests was just a number of records in the database table as someone just added a new record between these two tests. This is why it is important to interpret the results properly.