Public web applications are of interest to hackers as resources or earning tools. The range of application of the information obtained as a result of hacking is wide: paid access to a resource, use in botnets, etc. The identity of the owner is not important, since the hacking process is automated and put on stream. The cost of information is proportional to the visibility and influence of the company.
If you set a goal, there will be a vulnerability in the application. In the 2016 report on hacker attacks on websites, Google experts reported that the number of hacked resources increased by 32% compared to 2015, and this is not the limit. Remember this and discard the misconceptions about the inaccessibility of your web resources when planning information security work.
The tips described below will help you sort out and close the top-priority problems with the technical protection of the site.
Tips for protecting your web application from hackers
Use security analysis tools
This is what white hackers use in their work . Test your application with automated tools before manually looking for vulnerabilities . They perform penetration tests, try to break it, for example, using SQL injection.
Below is a selection of free tools.
Applications and frameworks
- OpenVAS scans hosts for vulnerabilities and allows you to manage vulnerabilities.
- The OWASP Xenotix XSS Exploit Framework scans a resource for the possibility of exploiting XSS vulnerabilities.
- Approof from Positive Technologies checks the configuration of a web application, scans for vulnerable components, insecure sensitive data and malicious code.
- SecurityHeaders.io checks for the presence and correctness of the server response headers that are responsible for the security of the web application.
- Observatory by Mozilla scans the resource for security issues. In addition to its results, when choosing the appropriate option, it collects and adds analytics from third-party security analysis services to the report.
- One button scan scans resource components for vulnerabilities: DNS, HTTP headers, SSL, sensitive data, services used.
- The CSP Evaluator verifies that the content security policy (CSP) is well written and XSS resilient.
- SSL Server Test analyzes the SSL configuration of a web server.
- ASafaWeb checks for common vulnerabilities in the configuration of sites written in ASP.NET.
Automated test results are disconcerting as they show all sorts of potential threats. But an explanation is attached to every problem identified. Analyze and correct critical comments first.
After you have made the recommended security changes to your application, rescan your application to ensure that you have taken the correct action.
If automatic verification is not enough, try to manually hack your resource by changing the values of POST and GET requests. A debug proxy server (such as Fiddler ) can help here , as it intercepts the values of HTTP requests between the browser and the server. Pay special attention to forms – try to bypass validation to implement XSS injection.
If your site has pages that are only accessible after authentication, try impersonating a different user. To do this, change the URL parameters (for example, user ID) or cookie values.
Protect user data with HTTPS
HyperText Transfer Protocol Secure (HTTPS) is an HTTP extension that supports encryption and protects user data in transit over the Internet. HTTPS guarantees the integrity and confidentiality of communication with the server. HTTPS hit a tipping point in March this year , and its use will soon become the “norm” and not the exception as it used to be.
Use HTTPS if users send personal data to the server: credit card information, personal data, and even the addresses of the pages they visited. If, when sending data from the authorization form, cookies are set, which are then sent with each request to the server, an attacker can obtain them and forge a request to the server. As a result, it will intercept the user’s session. To prevent this, use HTTPS on all pages on your site.
It’s simple: an SSL certificate is generated for free (for example, on Let’s Encrypt ), for most platforms, tools have been created to automatically obtain and install a certificate. All that remains is to enable HTTPS support on the server.
Notably, Google has announced plans to give sites using secure connections an advantage in search results. This is gingerbread. The whip will be warnings about unsafe connections in browsers, the number of which will grow. HTTP is a thing of the past, so it’s time to switch to HTTPS.
If HTTPS is already configured, it is good practice to use HTTP Strict Transport Security (HSTS), a server response header that prevents the domain from using an unsecured connection.
Update your software
This is vital to the security of the web application. Hackers regularly discover and immediately apply new vulnerabilities in operating systems and other software: HTTP servers or content management systems (CMS).
If the resource is located on the server of the hosting provider, then the installation of updates for the operating system is included in the range of services. Otherwise, you need to update the operating system yourself.
If the resource is powered by a third-party engine (CMS or forum), install security fixes immediately after release. Most developers provide updates via a newsletter or RSS feed with a description of the fixed issues. WordPress and Umbraco also notify of available updates when you log into your dashboard.
Many developers use package managers (such as Composer, NPM, or RubyGems) to install dependencies for their applications. These packages are also found to contain vulnerabilities, so stay tuned for updates. Use tools like Gemnasium to automatically be notified of security issues in your project packages .
Prevent SQL injections
SQL injection is the execution of an arbitrary query against the application database using a form field or URL parameter. If you are using Standard Transact SQL, it is possible to insert malicious code. As a result, table data will be received, changed or deleted. To prevent this, use parameterized queries, which are supported by most web programming languages.
Consider the request:
SELECT * FROM table WHERE column = 'parameter';
If an attacker changes the value
' OR '1'='1, the request will look like this:
SELECT * FROM table WHERE column = '' OR '1'='1';
'1', the attacker will have access to all the data in the table. This will execute an arbitrary query by appending the SQL statements to the end.
The vulnerability of this query can be easily fixed using parameterization. For example, for an application written using PHP and MySQLi, it looks like this:
$stmt = $pdo->prepare('SELECT * FROM table WHERE column = :value'); $stmt->execute(array('value' => $parameter));
Prevent cross-site scripting
Cross-site scripting (XSS) is a type of attack on web resources that injects malicious code into a website page that runs on the user’s computer, modifies the page and transfers the stolen information to the attacker.
Modern web applications are especially susceptible to this type of attack, where pages are built from user-generated content, interpreted by front-end frameworks like Angular and Ember. These frameworks have built-in cross-site scripting protection, but mixing server-side and client-side content shaping creates new complex attacks: injecting Angular directives or Ember.
When checking, focus on user-generated content to avoid misinterpretation by the browser. This is similar to SQL injection protection. When generating HTML code dynamically, use special functions to change and retrieve attribute values (for example,
element.textContent), as well as templating engines that automatically escape special characters.
Content Security Policy (CSP) is another tool for protecting against XSS attacks. CSP – server headers that define the whitelist of sources from where data loading for different types of resources is allowed. For example, prohibiting the launch of scripts from a third-party domain or disabling a function
eval(). CSP policies make it impossible to execute even if malicious code is injected into a page. The official Mozilla website hosts a CSP manual with configuration examples .
Check and encrypt passwords
Store passwords as a hash, and it is better to use one-way hashing algorithms such as SHA. In this case, hashed values are compared to authorize users. If an attacker breaks into the resource and obtains hashed passwords, the damage will be reduced due to the fact that the hash has an irreversible effect and it is almost impossible to get the initial data from it. But hashes for popular passwords can be easily searched through a dictionary, so also use a “salt” that is unique for each password. Then cracking a large number of passwords becomes even slower and more computationally expensive.
With regard to validation, set a limit on the minimum password length, and also check for matches with the login, e-mail and site address.
Fortunately, most CMSs provide security policy management tools, but sometimes additional configuration or module installation is required to use the salt or set the minimum password complexity. When using .NET, it is worth using membership providers because they have built-in security with a lot of settings and ready-made elements for authentication and password change.
Control the file upload process
Uploading files to a website by a user, even if it’s just a change of avatar, poses a threat to information security. The downloaded file, which, at first glance, looks harmless, may contain a script and, when executed on the server, will open an attacker access to the site.
Even if there is a restriction on the type (for example, only images), be suspicious of user-uploaded files. The extension or MIME-type is easy to spoof, reading the header or using the image size checking functions is not 100% guaranteed, it is possible to inject PHP code into most image formats, which will be executed on the server.
To prevent this, prevent users from executing the downloaded files. By default, web servers don’t try to execute files with image extensions, but don’t rely on the extension alone. There are known cases when a file
image.jpg.phpbypassed this check.
Access restriction methods:
- rename or change file extensions at boot;
- change permissions, for example, to
- create a file
.htaccess(see example below) that will open access only to the specified file types.
deny from all <Files ~ "^\w+\.(gif|jpe?g|png)$"> order deny,allow allow from all </Files>
A safer way is to deny direct access to downloaded files by placing them, for example, outside the site root folder. However, in this case, you will need to create a script (or an HTTP handler in .NET) to fetch the files from the private part and serve it to the user.
<img src="/imageDelivery.php?id=1234" /> <?php // imageDelivery.php // Извлекаем из базы данных имя файла изображения по ID ($_GET["id"]) ... // Передаём изображение браузеру Header('Content-Type: image/gif'); readfile('images/'.$fileName); ?>
Web application protection measures for owners of their own servers:
- Configure your firewall to block unused ports.
- If you have access to the server from your local network, create a demilitarized zone (DMZ), allowing access from the outside world to only ports 80 and 443.
- If you do not have access to the server from the local network, use secure methods (SFTP, SSH, etc.) to transfer files and control the server from the outside.
- If possible, provide a separate server for the databases that is not directly accessible from the outside world.
- Limit physical access to the server.
Watch for error messages
Be careful with what appears in application error messages. Inform the user about errors in the most concise form that excludes the presence of any technical information. Store detailed information in the server log files. After all, having complete information, it is easier for an attacker to carry out complex attacks like SQL injection.
To keep your finger on the pulse of the project, set up a bug monitoring system. For example, Sentry , which automatically receives errors from handlers in the application code and through the form from users, and also provides a panel for managing them in real time.
Check incoming data
Control the data received from web forms, both client-side and server-side. The browser checks for simple errors like a blank required field or text entered in a numeric field. These checks are bypassed, so server-side control is required. Lack of server-side validation leads to exploitation of injection and other types of attacks by the attacker.
Distribute file permissions
File permissions determine WHO and WHAT can do with it.
In * nix systems, files have 3 access options, which are represented as numbers:
- “Read” (4) – reading the contents of the file;
- “Write” (2) – change the content of the file;
- “Execute” (1) – execution of a program or script.
To set multiple permissions, just add their numeric values:
- “Read” (4) + “write” (2) = 6;
- Read (4) + Write (2) + Execute (1) = 7.
When distributing rights, users are divided into 3 types:
- “Owner” – the creator of the file (changeable, but there can be only one);
- “Group” – the group of users who get the permissions;
- “Others” – other users.
Setting read and write permissions for the owner, read permissions for the group, and others – denying access looks like this:
It is the same for directories, but the “execute” flag means to make it the working directory.
When installing, CMS permissions are usually set correctly from a security point of view. However, on the Internet it is often advised to solve permissions problems by setting all files to
777. This tip helps to solve the problem, but it opens up a serious vulnerability, because everyone has the right to change (insert malicious code) or delete files on the server. Distribute file access rights on the server in accordance with the tasks of the users.
We’ve also rolled out a useful roadmap for a back-end developer that touches on the basic tools and technologies for securing a web application.