Tips on how to secure your website from hacker attacks
Today’s realities show ever-growing attacks on web applications – up to 80% of systems compromise cases begin with a web application. This article will discuss the most common vulnerabilities that attackers actively use, as well as effective methods of countering them using the Web Application Firewall.
With the increase in the number of tools and attack techniques, it becomes increasingly difficult to ensure the availability of the site, to protect the Web application or its components from hacking and content spoofing. Despite the efforts of technical experts and developers, the defending side traditionally takes a catching-up position, implementing protective measures after the web application has been compromised. Websites are attacked due to public availability, not always to the quality written code, the presence of errors in the configuration of the server part, as well as to the lack of monitoring by the IS service, thereby providing access to critical data for intruders.
In this regard, there is a need to use security tools that take into account the architecture of the web application, and do not lead to delays in the work of the site.
Zero Day Vulnerabilities
A zero-day or 0-day vulnerability is a previously unknown vulnerability exploited by intruders. The origin of the term is due to the fact that the vulnerability or attack becomes publicly known until the software manufacturer releases the bug fixes (that is, potentially the vulnerability can be exploited on working copies of the application without being able to protect itself from it).
The nature of zero-day vulnerabilities allows attackers to successfully attack web applications in a period of several minutes to several months. Such a long period is due to a number of factors:
- Vulnerability needs to be localized and eliminated;
- Roll out a workable patch;
- Notify users of the problem;
- Users of the application to launch the process of patch management (which can be very difficult to do “here and now” on a large project);
This is another important factor: for a new vulnerability, there may not exist rules or exceptions in the defense system, and the attack signature may not be recognized by classical defenses. In this case, use the white list of behavioral analysis of a particular web application to minimize the risks of zero-day attacks.
An example is the chronology of the Struts2 attack: CVE-2013-2251 Struts2 Prefixed Parameters OGNL Injection Vulnerability – Since the advent of the “combat” exploit, it took several days before many companies were able to roll the patch.
Nevertheless, with the use of protective means, it was possible to identify a request for the form:
http://host/struts2-blank/example/X.action?action:%25{(new+java.lang.ProcessBuilder(new+java.lang.String[]{'command','goes','here'})).start()}
To block an attack, because It is clearly not legitimate in the context of user actions.
Classic attacks
Statistics show that many web applications are compromised as they were years ago – these are all kinds of injections, include, client-side attacks, so the security tool should be able to identify and block attacks aimed at exploiting the following vulnerabilities:
- SQL Injection – SQL injection;
- Remote Code Execution (RCE) – remote code execution;
- Cross Site Scripting (XSS) – cross site scripting;
- Cross Site Request Forgery (CSRF) – interstate forgery of requests;
- Remote File Inclusion (RFI) – remote included;
- Local File Inclusion (LFI) – local инклуд;
- Auth Bypass – bypass authorization;
- Insecure Direct Object Reference – unsafe direct links to objects;
- Bruteforce – the selection of passwords.
In an ideal web application, this type of vulnerability should be detected and fixed at the design stage: a static, dynamic, interactive analysis should be performed, anomalies in the application logic should be identified. But, often, such moments are for one reason or another left out of sight, they do not have time or money.
Protection at the application level
Web applications differ from ordinary applications in two ways: great variety and considerable interactivity. This creates a number of new threats, with which traditional firewalls can not cope.
The application layer protocol is the protocol of the upper (7th) level of the OSI network model, it provides interaction between the network and the user. The layer allows the user’s applications to access network services, such as a database query handler, file access, and e-mail forwarding. Protection at the application level is the most reliable. Vulnerabilities exploited by intruders often rely on complex user input scenarios, which makes them difficult to determine using classic intrusion detection systems. Also, this level is the most accessible from outside. There is a need to understand the groups of protocols and dependencies inherent in web applications that are built on the Http / https application protocols.
The main principle of site protection at the application level is the verification and filtering of data from requests transmitted by GET, POST, etc. methods. Changing or modifying the request is the basic basis of almost all methods of hacking and attacks on sites.
Objectives of attacks
Web applications can be attacked regardless of their belonging to a particular field of activity: small-attendance sites that do not operate with large amounts of information and do not store critical data can be attacked as a result of non-targeted attacks. Significant sites with high traffic figures, huge amounts of user data, etc. Are an attractive target for intruders and are attacked almost daily:
- Every third site was hacked or attacked by hackers;
- 80% of sites are hacked during non-targeted attacks using popular scanners or utilities;
- About 60% of hacked sites were infected and blocked by search engines.
For sites that operate with payment data processing online transactions, there are specialized requirements for compliance with the PCI DSS standard. Payment Card Industry Data Security Standard (PCI DSS) is a standard of payment card industry data security developed by the Payment Card Industry Standards Council (PCI SSC), established by the international payment systems Visa, MasterCard, American Express, JCB And Discover.
Paragraph 6.6 states that in addition to the audit of the web application, it is necessary to ensure the use of specialized protective equipment:
To gain a better understanding of the Requirement 6.6, we should refer to PCI DSS 3.1 standard which says that public-facing web applications shall “address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks.”
What is important here is the “on an ongoing basis” condition, which makes it very clear that web security is a permanent process and highlights the importance of continuous web security.
PCI DSS proposes two ways to achieve this requirement:
“Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes.”
“Installing an automated technical solution that detects and prevents web-based attacks (for example, a web application firewall) in front of public-facing web applications, to continually check all traffic.”
Paragraph 6.6 is mandatory if the web application is included in the CDE (Cardholder Data Environment).
Securing the site
The best solution for securing the site is to use the Web Application Firewall, an application-level firewall that allows you to effectively protect your sites from malicious attacks.
Web Application Firewall is a special mechanism that imposes a certain set of rules on how the server and client interact with each other, processing HTTP packets. At the core lies the same principle as in conventional custom firewalls, monitoring all data that comes from outside. The WAF relies on a set of rules to identify the fact of an attack on signatures – signs of user activity that could mean an attack.
How it works
Web Application Firewall works in the transparent proxy mode, I analyze on the fly the data coming from the client and discarding illegitimate requests:
After installing the Web Application Firewall, you need to configure it for the target web application depending on the type and type of CMS, the filtering settings, and rules that apply to the Web application are added and the protection is transferred to the training mode, to collect reference communication models with the web application, identifiers, and .
After the machine learning phase, the combat mode is activated, which operates both ready-made filtration rules and the workings collected at the training stage to detect and block attacks.
The effectiveness of using the Web Application Firewall is made up of several factors:
- Simple integration into the infrastructure;
- Flexible system of adaptation with a web application;
- Blocking Threats OWASP Top 10;
- Analysis and blocking of protocol or data anomalies;
- Detection and blocking of falsification of session identifiers;
- Detection and blocking the selection of passwords;
- Inspect server responses for critical data;
- Dynamic update of attack signatures;
- Low number of false positives;
- Self-defense WAF;
- A convenient service for informing about attacks;
- Statistics and regulatory reporting;
One of the sources to identify new scenarios and implement attacks on web applications is the “Penetration testing labs”, simulating the real infrastructure of modern companies. About 9000 information security specialists from all over the world take part in the laboratories, with different levels of training, skills, and tools. The analysis of attacks aimed at the objects of the laboratory, make it possible to make models of the offender and the implementation of attack vectors.
These data are carefully analyzed and new filtering rules are added on their basis. Thus, our solution is able to provide full protection of the site from various types and types of attacks.
Nemesida WAF is an application-level firewall (Web Application Firewall) that effectively protects websites from hacker attacks even if there is a “zero-day” vulnerability on the site.
