How does the Web application firewall provide protection for customers?

Web-based applications require security value-added vendors and system integrators to install, configure, and support firewall devices for a series of web application firewall services. Firewall Products, because of its assistance in complying with the Payment Card Industry Data Security Standard pci dss, have obtained all the code that is concerned with PCI regulation 6.6 requiring organizations to check web applications themselves, or install a Web application firewall to prevent known attack methods). For organizations that provide web access to their applications, they have become necessary.

What is Web application firewall?
Web application firewall is designed to protect web-based applications. Unlike traditional firewalls, it monitors and blocks data packets based on internet addresses and port numbers. A standard port number corresponds to a network application type. For example, telnet receives packets sent to port 23, and the mail server receives packets sent to port 25.

The traditional firewall allows data to be sent to the corresponding Internet address of the email server, so that data packets can be sent to the destination through port 25. Sending data packets to an Internet address or port 25 of the email server system is an attack. The firewall blocks these packets.

The Web server should transmit data packets through port 80. Therefore, all data packets sent to support port 80 of the web server system must be allowed to pass through the firewall. Traditional firewalls cannot determine whether a packet whose address points to the correct address contains threats. However, Web application firewall can carefully check the packet content to detect and prevent threats.
How can Web applications be attacked?

Hackers constantly develop new methods to gain unauthorized Web application access, but there are also some common technologies.

• SQL Injection: Some Applications create database queries by copying Web client input. Hackers construct strings that are not carefully checked and rejected by some applications to obtain the returned confidential data.
• Cross-site Scripting: a hacker inserts a script code such as JavaScript or ActiveX into an input string, causing information such as the user name and password to be leaked on the Web server.
• Operating System Command Injection: Some applications use web Input to create operating system commands, just like accessing a file and displaying the file content. If the input string does not have a careful check mechanism, hackers can create input to display unauthorized data, modify files or system parameters.
• Session hijacking: hackers obtain the right to log on to a session by guessing the content of the session Token Based on the token format knowledge. This allows hackers to take over sessions and obtain the original user account information.
• Tampered parameters or urls: web applications usually embed parameters and URLs in the returned web pages, or use authorized parameters to update the cache. Hackers can modify these parameters, URLs, or caches so that the Web server returns information that should not be leaked.
• Buffer overflow: the application code should check the length of the input data to ensure that the input data does not exceed the remaining buffer and modify adjacent storage. Hackers will soon find that the application does not check for overflow and create input to cause overflow.

How to Prevent web application attacks

The Web application firewall checks the content of each incoming packet to detect the above attacks. For example, the web application firewall scans SQL query strings to detect and delete strings that are required by redundant applications for returned data. Value-added vendors should carefully monitor new attack types and track and detect their latest products.

The Web Application Firewall not only detects known types of attacks, but also monitors abnormal usage modes to detect unknown attack methods. For example, the number of information exchanges between Web applications and web clients is limited. If the Web application firewall detects that the Web server is returning a much larger data volume than expected, it will cut off the transmission in time to prevent more data leaks.

Currently, WAF is based on software and applications. Software-based products are deployed on Web servers, while applications-based products are placed between Web servers and Internet interfaces. Both types of firewalls check data before data is transmitted to and from the web server.

Software-based products generally cost less than application-based products. software-based product vendors claim that such firewalls have lower latency and higher throughput. However, installing additional software on the web server will inevitably increase the processing load and complexity of the software on the system.

Application-based Firewall vendors claim that such firewalls are easy to install and use because no additional software is installed on the Web server system. The performance of the Web server is not affected by the processing of the Web application firewall.

In addition to commercial products, there are also many open source Web application firewalls available. The cost of these products is lower than that of commercial products. For open source code tools, they are free, or commercial products based on open source code are very likely to reduce costs ). In the past, open-source code was concerned that hackers will check the code and try to escape protection measures. With rich experience in open-source software such as Linux, these are not a problem.

All products, whether purchased or open source code, software-based or application-based, should be supported. Commercial Products are supported by suppliers. Open source provides an opportunity for value-added vendors and system integrators to integrate security knowledge. Provides continuous support for Web application firewalls, ensures close relationships between partners and customers, and provides suppliers with more products and services in the future.

Because each customer's environment and application settings are different, VARs and system integrators must evaluate each customer's unique needs to determine which type of Web application firewall is most appropriate. However, there is no doubt that all customers' Web applications should be protected by the Web application firewall. If the user does not understand this requirement or does not agree with this practice, it is necessary to introduce to them various ways in which Web applications may be attacked.

Checking the application code carefully is a way to replace the web application firewall. All attacks are successful in the case of compilation errors or lack of internal data checks. Theoretically, a web application that uses code inspectors to inspect errors row by row can replace the web application firewall.

In practice, although software engineers do not often believe that their code is defective, the constant updates to the application make detailed code checks almost impossible, not to mention that code inspectors can easily ignore Insecure code, especially those with no security background. In addition, hacker technology has developed rapidly. Network Firewall vendors always pay attention to new attack types and update their products in a timely manner. Some customers may think that code-reviewed programs can help them avoid the cost and workload of implementing a web application firewall, however, solution providers should help customers realize that security code review can only bring false security. In fact, it cannot replace the comprehensive security protection provided by waf.

1. 10 things you should pay attention to when choosing a hardware firewall
2. In-depth understanding of the firewall to effectively shield external attacks
3. Analysis on the classification and limitations of firewall functions