The disadvantage of HTTP

So far, we have learned that HTTP has a very good and convenient side. However, HTTP has not only a good side but also a bad side. Every coin has two sides. HTTP has these major shortcomings, as listed below. 1, communication using clear text (not encrypted), the content may be eavesdropped

The identity of the communication party is not verified and therefore may be disguised. 3. The integrity of the packet cannot be proved and may be tampered with. In addition, HTTP itself has many drawbacks. There are also practical limitations (also known as vulnerabilities or security holes) with specific Web servers and specific Web browsers, as well as security holes for Web applications developed in programming languages such as Java and PHP.

Communications using plaintext may be eavesdropped

HTTP itself does not have the function of encryption, so it cannot be used to encrypt the communication as a whole (the content of requests and responses communicated using HTTP). That is, HTTP packets are sent in plaintext (unencrypted packets).

TCP/IP is a network that can be eavesdropped on

If you ask why not encrypting communication is a disadvantage, it is because the TCP/IP protocol family works so that the content of communication can be accessed over all communication lines.

The so-called Internet is made up of networks that can connect to the whole world. No matter which corner of the world when the server and client communication, in this communication line on some network equipment, optical cable, computer, etc., can not be a personal private thing, so do not exclude a link will be malicious peep behavior.

Even encrypted communications can be seen, just as unencrypted communications are. It’s just that if the communication is encrypted, it might be impossible to decipher the meaning of the message, but the message itself can still be seen after the encryption.

Graph: Any corner of the Internet is at risk of eavesdropping on communications, and it is not difficult to eavesdrop on the same segment of communications. Just collect the packets (frames) that flow over the Internet. The parsing of collected packets can be handed over to PacketCapture or Sniffer tools.

Encryption prevents eavesdropping

At present we are studying how to prevent eavesdropping to protect information of several countermeasures, the most popular is encryption technology. There are several objects that can be encrypted. Encrypting communication One way to encrypt communication is to encrypt it. HTTP has no encryption mechanism, but it can be used in combination with Secure Socket Layer (SSL) or Transport LayerSecurity (TLS) to encrypt HTTP traffic. After establishing a secure communication line with SSL, HTTP communication can be carried out over this line. The HTTP used in combination with SSL is called HTTPS (HYPERtext Transfer Security Protocol) or HTTP over SSL.

Content encryption There is also a way to encrypt the content itself that participates in the communication. Since there is no encryption mechanism in HTTP, the content transmitted over HTTP is encrypted. That is, the content in HTTP packets is encrypted.

In this case, the client needs to encrypt the HTTP packet before sending the request.

Admittedly, in order to achieve effective content encryption, both the client and the server are required to have encryption and decryption mechanisms. It is mainly used in Web services. It is important to note that, unlike SSL or TLS, which encrypt the entire communication line, the content is still at risk of tampering. We’ll explain that later.

Failure to verify the identity of the communicating party may result in a masquerade

Requests and responses in HTTP do not acknowledge the communicator. That is, there are questions like “is the server really the host specified in the URI that sent the request, and is the response actually returned to the client that actually made the request?”

Anyone can initiate a request

In HTTP communication, anyone can initiate a request because there is no step to confirm the communicator. In addition, the server will return a response whenever it receives a request, regardless of who it is (but only if the IP address and port number of the sender are not restricted by the Web server).

HTTP protocol implementation itself is very simple, no matter who sent the request will return a response, so do not confirm the communication party, there are various hazards. 1. It is not possible to determine whether the Web server to which the request is sent is the one that returns the response as intended. It could be a disguised Web server. 2. It is not possible to determine whether the client to which the response is returned is the client that received the response as intended. It could be a disguised client. 3. You cannot determine whether the communicating party has access permission. Because some Web servers hold important information, they only want to give specific users permission to communicate. 4. There is no way to determine where or by whom the request came from.

5. Even meaningless requests will be accepted. Denial of Service (DoS) attacks on massive requests cannot be prevented.

Find out your opponent’s credentials

Although the communication party cannot be determined using the HTTP protocol, it can be determined using SSL. SSL not only provides encryption, but also uses a device called a certificate that can be used to determine the party. The certificate is issued by a trusted third-party organization to prove that the server and client actually exist. In addition, forging certificates is technically extremely difficult. Therefore, as long as the certificate held by the communicator (server or client) can be confirmed, the true intention of the communicator can be determined.

Use certificates to prove that the communicating party is the intended server. This reduces the risk of personal information disclosure for users. In addition, the client can complete the confirmation of personal identity by holding the certificate, and can also be used for the authentication of Web sites.

Message integrity could not be proved and may have been tampered with

Completeness refers to the accuracy of information. Failure to prove its completeness usually means it is impossible to determine whether the information is accurate.

The content received may be incorrect

The HTTP protocol cannot prove the packet integrity of communication. Therefore, it is impossible to know whether the content of a request or response has been tampered with until the request or response is received. In other words, there is no way to confirm that the request response sent and received is the same.

 

For example, when downloading content from a Web site, it is impossible to determine whether the files downloaded by the client are the same as those stored on the server. The contents of the file may have been tampered with in transit. Even if the content does change, the client on the receiving end is not aware of it. Such attacks are called man-in-the-middle attacks (MITM) in which a request or response is intercepted and tampered with while in transit.

How to Prevent tampering

Although there is a method to determine packet integrity using HTTP protocol, it is not convenient and reliable. The commonly used hashing methods are MD5 and SHA-1, as well as digital signature methods used to confirm files.

Web sites that provide file download services also provide digital signatures created using PGP (Pretty GoodPrivacy) and hashes generated by the MD5 algorithm. PGP is used to prove the digital signature used to create the file, and MD5 is a hash value generated by a one-way function. In either case, the user manipulating the client needs to personally verify that the downloaded file is the same as the file on the original server. Browsers don’t automatically check for users. Unfortunately, there is still no guarantee that the results are correct using these methods. Since PGP and MD5 are rewritten, there is no way for users to notice.

To effectively prevent these disadvantages, it is necessary to use HTTPS. SSL provides authentication, encryption, and summary functions. It is very difficult to ensure integrity with HTTP alone, so use it in combination with other protocols to achieve this goal. We’ll cover HTTPS in the next section.

HTTPS to ensure Web security

Security problems such as information interception and identity disguise may exist in HTTP protocol. Using the HTTPS communication mechanism can effectively prevent these problems.

HTTP+ Encryption + Authentication + Integrity Protection =HTTPS

HTTP is HTTPS with encryption, authentication, and integrity protection. If you use unencrypted plaintext during HTTP communication, such as entering a credit card number on a Web page, the credit card number is exposed if the communication line is bugged. In addition, in the case of HTTP, there is no way for the server or client to identify the communication party. It is possible that you are not actually communicating with the intended party. You also need to consider the possibility that the received message has been tampered with during communication. In order to solve these problems, encryption and authentication mechanisms need to be added to HTTP. We call HTTP with encryption and authentication mechanisms HTTPS (HTTP Secure).

HTTPS is often used for communication on the Web login page and shopping and settlement page. When using HTTPS for communication, use https:// instead of http://. In addition, when a browser visits a Web site with valid HTTPS communication, a lock symbol appears in the browser’s address bar. The display of HTTPS varies from browser to browser.

HTTPS is HTTP in an SSL shell

HTTPS is not a new protocol at the application layer. The HTTP communication interface is replaced by SSL (SecureSocket Layer) and TLS (Transport Layer Security) protocols. Typically, HTTP communicates directly with TCP. When SSL is used, it evolves to communicate with SSL first and then with SSL and TCP. In short, HTTPS is HTTP in the shell of THE SSL protocol.

With SSL, HTTP has the encryption, certificate, and integrity protection features of HTTPS. SSL is independent of HTTP. Therefore, SSL can be used with other protocols, such as SMTP and Telnet, that run on the application layer. SSL is arguably the most widely used network security technique in the world today.

Public-key encryption in which keys are exchanged

Before we get into SSL, let’s look at encryption methods. SSL uses a type of encryption called public-key cryptography.

In modern encryption methods, the encryption algorithm is open, but the key is secret. In this way the encryption method can be kept secure. Encryption and decryption use keys. A password cannot be decrypted without a key; conversely, anyone with a key can decrypt it. If the key is obtained by an attacker, the encryption is meaningless.

The dilemma of shared key encryption

Encryption and decryption using the same key is called Common key cryptosystem, also known as symmetric key encryption.

 

If the shared key is used for encryption, you must also send the key to the peer party. But how do you do it safely? When a key is forwarded over the Internet, if the communication is monitored the key can fall into the hands of an attacker, thus losing the purpose of encryption. You also have to secure the keys you receive.

Public key encryption using both keys

Public key encryption solves the difficulty of shared key encryption. Public-key encryption uses a pair of asymmetric keys. One is called a private key and the other is called a public key. As the name implies, a private key cannot be known to anyone else, whereas a public key can be freely distributed and available to anyone. A public key and a private key are paired. In public-key encryption mode, the sender uses the public key of the other party to encrypt the ciphertext. After receiving the encrypted message, the other party uses its private key to decrypt the encrypted message. In this way, there is no need to send the private key for decryption, and there is no need to worry about the key being eavesdropped and stolen by an attacker. In addition, it is extremely difficult to recover the original information based on ciphertext and public keys, because the decryption process involves evaluating the discrete logarithm, which is not easy to do. At the very least, if you can factor a very large integer quickly, there is hope for password cracking. But it’s not realistic with the current technology.

HTTPS uses a hybrid encryption mechanism

HTTPS uses a mixture of shared key encryption and public key encryption.

However, public key encryption is slower than shared key encryption. Therefore, we should make full use of their respective advantages and combine a variety of methods for communication. Public key encryption is used in the key exchange and shared key encryption is used in the subsequent stage of establishing communication exchange messages.

A certificate certifying the correctness of a public key

Unfortunately, there are some problems with public-key encryption. It is impossible to prove that the public key itself is a genuine public key. For example, how to prove that the public key received is the public key issued by the intended server when you are trying to establish public-key encryption communication with a certain server. Perhaps the real public key has been replaced by an attacker during the public key transfer. To solve the above problems, public key certificates issued by a digital Certificate Authority (CA) and its related authorities can be used. A digital certificate Authority is in the position of being a trusted third party organization for both client and server. VeriSign is one of the most well-known digital certification bodies. Let’s take a look at the business process of a digital certificate authority.

First, the server operator applies for a public key from a digital certificate Authority. After identifying the identity of the applicant, the digital certificate Authority will digitally sign the applied public key, allocate the signed public key, and bind the public key into the public key certificate. The server sends the public key certificate issued by the Digital Certificate Authority to the client for public key encryption communication. Public key certificates can also be called digital certificates or simply certificates. The client receiving the certificate can use the public key of the DIGITAL certificate Authority to verify the digital signature on the certificate. Once the authentication is successful, the client can know two things: first, the public key of the authentication server is a real and valid digital certificate authority. Second, the server’s public key is trustworthy. The public key of the authentication authority here must be securely transferred to the client. When using communication methods, it is difficult to secure the transfer, so most browser developers release versions with the public key of the common authentication authority embedded beforehand.

Secure communication mechanism of HTTPS

To better understand HTTPS, let’s look at HTTPS communication steps.

Step 1: The Client sends a Client Hello packet to start SSL communication. The packet contains the specified VERSION of SSL supported by the client and the Cipher Suite list (encryption algorithm and key length). Step 2: When SSL communication is enabled, the Server responds with Server Hello packets. As with the client, the message contains the SSL version as well as the encryption component. The server’s encryption component content is filtered from the received client encryption component. Step 3: Then the server sends a Certificate packet. The message contains a public key certificate. Step 4: The Server sends a Server Hello Done packet to notify the client that the INITIAL SSL handshake negotiation is complete. Step 5: After the first SSL handshake, the Client responds with a Client Key Exchange packet. The packet contains a random password string called pre-master secret, which is used in communication encryption. The packet is encrypted with the public key in Step 3. Step 6: The client sends a Change Cipher Spec packet. The packet prompts the server that the communication after the packet is encrypted with the pre-master secret key. Step 7: The client sends a Finished packet. The packet contains the overall checksum of all packets so far connected. Whether the handshake negotiation can succeed depends on whether the server can decrypt the packet correctly.

Step 8: The server also sends a Change Cipher Spec packet. Step 9: The server also sends a Finished packet.

Step 10: After exchanging Finished packets between the server and client, the SSL connection is established. Of course, the communication is protected by SSL. This is where application layer protocol communication starts, that is, sending HTTP requests. Step 11: Application layer protocol communication, that is, sending HTTP responses. Step 12: Finally disconnect from the client. When the connection is disconnected, the close_notify packet is sent. After this step, a TCP FIN packet is sent to close the communication with TCP. In the preceding process, the application layer attaches a Message Authentication Code (MAC) digest to the data it sends. The MAC checks whether packets are tampered to protect packet integrity. Below is a diagram of the process. The figure illustrates the entire process of establishing HTTPS communication from using only server-side public key certificates (server certificates).

The SSL and TLS

HTTPS uses the Secure Socket Layer (SSL) and Transport LayerSecurity (TLS) protocols. SSL technology was pioneered by browser developer Netscape Communications, which developed versions prior to SSL3.0. At present, the initiative has been transferred to the Internet Engineering Task Force (IETF). IETF developed TLS1.0, TLS1.1 and TLS1.2 based on SSL3.0. **TSL is based on SSL and is sometimes referred to as SSL. ** The current mainstream versions are SSL3.0 and TLS1.0. The SSL1.0 protocol was never put into use because problems were found at the beginning of its design. SSL2.0 was also found to have problems, so many browsers simply scrapped the protocol version.

Is SSL slow

The problem with HTTPS is that it slows down when SSL is used.

 

There are two types of SSL slowness. One is slow communication. On the other hand, the processing speed slows down due to the large consumption of CPU and memory resources. 1. Network load can be 2 to 100 times slower than using HTTP. In addition to TCP connections and SENDING HTTP requests and responses, SSL communication is required, which inevitably increases the overall traffic volume. 2. Another point is that SSL must be encrypted. Encryption and decryption are required on both the server and client. As a result, more hardware resources are consumed by the server and client than HTTP, resulting in increased load. There is no fundamental solution to the slow speed problem, we will use hardware like SSL accelerators to improve the problem. The hardware is dedicated to SSL communication, which can improve the computing speed of SSL several times compared with software. Use the SSL accelerator only for SSL processing to share the load.

Why not use HTTPS all the time

If HTTPS is so secure, why don’t all Web sites use HTTPS all the time? One reason is that encrypted communication consumes more CPU and memory resources than plain text communication. If every communication is encrypted, it consumes a considerable amount of resources, and the number of requests that can be processed on a single computer is bound to decrease. Therefore, HTTP is used for non-sensitive information and HTTPS is used for encrypted communication only when sensitive data such as personal information is included. Especially when the most visited Web sites in the encryption process, they bear the load should not be underestimated. When encrypting, not all content is encrypted, but only those that need to be hidden to save resources.

In addition, the desire to save on the cost of purchasing certificates is also a reason.

Certificates are essential for HTTPS communication. The certificates used must be purchased from a certification authority (CA). Certificate prices may vary slightly depending on the certification body. Typically, a one-year license costs tens of thousands of yen (10,000 yen is now about 600 yuan). Services that do not pay for certificates, as well as personal web sites, may simply choose to use HTTP for communication.

SPDY eliminates HTTP bottlenecks

The bottleneck of HTTP

On social networking sites such as Facebook and Twitter, it is also fun to watch a large number of users’ public posts almost in real time. When hundreds or tens of millions of users post content, Web sites can undergo massive content updates in a very short period of time to preserve the new content. In order to display the updated content in as real-time as possible, as soon as the content is updated on the server, that content needs to be directly fed back to the client interface. Although it seems simple enough, HTTP does not handle this task well. Using the HTTP protocol to detect content updates on the server requires frequent confirmations from the client to the server. If there are no content updates on the server, then fruitless communication occurs. The following HTTP standards become bottlenecks if you want to implement the desired functionality on the existing Web.

1. Only one request can be sent on a connection.

2. Requests can only start from the client. Clients cannot receive instructions other than responses. 3. Request/response headers are sent uncompressed. The more headers, the greater the delay.

4. Send lengthy headers. Sending the same headers each time causes more waste.

5, optional data compression format. Uncompressed send.

Ajax solution

Ajax (Asynchronous JavaScript and XML) is an operation that makes efficient use of JavaScript and DOM (Document Object Model). Asynchronous communication means to achieve partial Web page replacement loading. Because it updates only a portion of the page, the amount of data transferred in the response is reduced, which is an obvious advantage over previous synchronous communication.

The core technology of Ajax is an API called XMLHttpRequest, which enables HTTP communication with the server through the invocation of the JavaScript scripting language. This allows you to make a request from a loaded Web page and update only part of the page.

Getting content from the server in real time with Ajax can result in a lot of requests. In addition, Ajax still does not solve the problems of the HTTP protocol itself.

Comet solutions

Once something is updated on the server side, Comet does not wait on the request, but returns a response directly to the client. This is a function that simulates the Server Push to the client by delaying the response.

Normally, the server would receive the request and return the response as soon as it was processed, but for pushing, Comet would suspend the response and return it when something was updated on the server. Therefore, as soon as there is an update on the server side, it can be immediately reported back to the client side.

Content can be updated in real time, but the duration of a connection is longer to preserve the response. In the meantime, more resources are consumed to maintain the connection. In addition, Comet still doesn’t solve problems with the HTTP protocol itself.

The goal of SPDY

The advent of ease of use technologies, such as Ajax and Comet, has improved HTTP to some extent, but the limitations of the HTTP protocol itself have been somewhat frustrating. In order to make fundamental improvements, there need to be some protocol level changes. The SPDY protocol, which is in continuous development, is designed to eliminate HTTP bottlenecks at the protocol level.

Design and function of SPDY

Instead of rewriting HTTP completely, SPDY operates by adding a new session layer between the TCP/IP application layer and the transport layer. At the same time, for security reasons, SPDY specifies the use of SSL in communication. SPDY is added as a session layer that controls the flow of data, but still uses HTTP to establish communication connections. Therefore, HTTP methods such as GET and POST, cookies, and HTTP packets can be used as usual.

With SPDY, the HTTP protocol gains the following additional capabilities.

Multiplexed stream

Multiple HTTP requests can be processed without limit over a single TCP connection. All requests are processed on a single TCP connection, so TCP processing is more efficient.

Prioritize requests

Not only can SPDY process requests concurrently without limit, but it can also prioritize requests one by one. This is mainly to solve the problem of slow response caused by low bandwidth when multiple requests are sent.

Compressing HTTP headers

Compressing HTTP request and response headers. As a result, fewer packets are generated and fewer bytes are sent.

Push function

Supports the server to actively push data to the client. This way, the server can send data directly without waiting for the client to request it.

Server prompt function

The server can actively prompt the client to request the required resources. Because the existence of a resource is known before the client discovers it, unnecessary requests can be avoided, for example, if the resource is cached.

Does SPDY eliminate the W EB bottleneck

You want to use SPDY without having to make any special changes to the content side of the Web, and both the Web browser and the Web server have to make some changes to accommodate SPDY. Several Web browsers have adapted SPDY accordingly. In addition, experimental applications of Web servers have been carried out, but the introduction of this technology into actual Web sites has not progressed well. Because SPDY basically just multiplexes the communications of a single domain name (IP address), the improvement is limited when resources under multiple domain names are used on a Web site. SPDY is certainly an effective technique for eliminating HTTP bottlenecks, but many Web sites have problems that are not solely caused by HTTP bottlenecks. There are other areas that can be studied more carefully to speed up the Web itself, such as improving the way Web content is written.

WebSocket that uses the browser for full-duplex communication

Using Ajax and Comet technologies to communicate can speed up Web browsing. However, the problem is that if HTTP protocol is used for communication, it cannot completely solve the bottleneck problem. WebSocket network technology is a new protocol and API to solve these problems. At the time, WebSocket was planned as part of the HTML5 standard, but now it is becoming a separate protocol standard. The WebSocket protocol was standardized by RFC 6455 – The WebSocketProtocol on December 11, 2011.

W ebSocket design and function

WebSocket is a standard for full-duplex communication between Web browsers and Web servers. The WebSocket protocol is standardized by IETF, and the WebSocket API is standardized by W3C. WebSocket technology, which is still under development, is designed to address problems caused by a bug that came with XMLHttpRequest in Ajax and Comet.

W ebSocket agreement

** Once the WebSocket protocol communication connection is established between the Web server and the client, all subsequent communication relies on this proprietary protocol. ** Data in any format, such as JSON, XML, HTML or pictures, can be sent to each other during communication. Because it is a protocol based on HTTP, the initiator of the connection is still the client. Once the WebSocket communication connection is established, either the server or the client can directly send packets to the other party. Let’s list the main features of the WebSocket protocol.

Push function

The server can push data to the client. This way, the server can send data directly without waiting for the client to request it.

Reduced traffic

As long as a WebSocket connection is established, you want it to stay connected. Not only is the total overhead per connection reduced compared to HTTP, but there is also less traffic due to the small size of the WebSocket header.

To implement WebSocket communication, after an HTTP connection is established, you need to complete a “Handshaking” step.

After a successful handshake establishes a WebSocket connection, communication uses websocket-independent data frames instead of HTTP data frames.

The long-awaited HTTP/2.0

The current mainstream HTTP/1.1 standard has not been revised since RFC2616 in 1999. With technologies like SPDY and WebSocket emerging, it’s hard to say HTTP/1.1 is still the protocol for today’s Web. Hypertext Transfer Protocol Bis (Hypertext Transfer Protocol Bis) was established by Internet Engineering Task Force (IETF), which is responsible for Internet technical standards. Datatracker.ietf.org/wg/httpbis/… HTTP – HTTP/2.0 was standardized in November 2014.

The characteristics of the HTTP / 2.0

The goal of HTTP/2.0 is to improve the user experience of speed when using the Web. Since TCP connections are generally made through HTTP/1.1 first, let’s take a look at how they are implemented based on the following protocols. SPDY HTTP Speed + Mobility network-friendly HTTP Upgrade HTTP Speed + Mobility is a standard developed by Microsoft to improve the communication Speed and performance of mobile terminals. It is based on SPDY and WebSocket proposed by Google. Network-friendly HTTP Upgrade is a standard for improving HTTP performance in mobile communication.

HTTP/2.0 7 technologies and discussion

HTTP/2.0 is discussed around seven major technologies, and at this stage (August 13, 2012), most of the following protocols are favored. But discussions are continuing, so major changes cannot be ruled out.



HTTP Speed + Mobility; network-friendly HTTP Upgrade;

Web attack techniques

Most attacks on the Internet target Web sites. This chapter explains how you can attack a Web site and what the impact is. The simple HTTP protocol itself does not have security problems, so the protocol itself is hardly the target of attack. HTTP servers, clients, and Web applications running on servers are the targets of attacks. At present, most attacks from the Internet are directed at Web sites, and most of them target Web applications. This chapter describes the attack technologies for Web applications.

HTTP does not have the necessary security features

Compared with the original design, the use of HTTP protocol has changed dramatically in today’s Web sites. Almost all Web sites today use security features such as session management and encryption, which are not available in HTTP. Taken as a whole, HTTP is a generic, pure protocol mechanism. So it has a lot of advantages, but in terms of security is a disadvantage. For example, SSH, which is used for remote login, provides protocol-level authentication and session management, while HTTP does not. In addition, in the aspect of setting up SSH services, anyone can easily create a high level of security services, and HTTP even if the server is set up, but if you want to provide Web applications based on the server, in many cases need to be redeveloped. Therefore, developers need to design and develop their own authentication and session management functions to meet the security of Web applications. Designing your own means a variety of implementations. As a result, the security level is incomplete, but the Web applications that are still in operation are riddled with bugs that can easily be abused by attackers.

The request can be tampered with on the client side

In Web applications, the entire content of HTTP requests received from the browser can be freely changed and tampered with on the client side. So a Web application might receive something different than the expected data.

You can launch attacks against Web applications by loading attack codes into HTTP request packets. Through THE URL query fields or forms, HTTP headers, cookies and other ways to enter the attack code, if there is a security vulnerability in the Web application at this time, the internal information will be stolen, or the attacker to get management rights.



There are two attack modes against Web applications.Take the initiative to attackandPassive aggression.

An active attack that targets the server

Active attack refers to an attack mode in which attackers directly access Web applications and pass in attack codes. Since this mode attacks resources on the server directly, the attacker needs to be able to access those resources. The representative attacks in active attack mode are SQL injection attack and OS command injection attack.

Passive attacks that target the server

Passive attack refers to an attack mode that uses trap strategies to execute the attack code. In the passive attack, the attacker does not attack the access of the target Web application directly.

Passive attack The following describes the common attack modes.

Step 1: The attacker induces the user to trigger a trap that triggers the sending of an HTTP request with embedded attack code.

Step 2: The user’s browser or email client triggers the trap when the user is unwittingly caught.

Step 3: After being tricked, the user’s browser sends the HTTP request containing the attack code to the Web application as the target to run the attack code.

Step 4: After the attack code is executed, the Web application with security vulnerabilities becomes a springboard for attackers, which may lead to the theft of personal information such as cookies and the abuse of user rights in the login state.

The representative attacks in passive attack mode are cross-site scripting and cross-site request forgery.





Attack enterprise internal network by using user identity

Using passive attack, you can launch attacks on enterprise networks that cannot be accessed directly from the Internet. Once a user steps into the trap set by the attacker, even the Intranet of the enterprise can be attacked within the network that the user can access.

Many enterprise intranets can still be connected to the Internet to access Web sites or receive emails from the Internet. This may give the attacker a chance to induce users to trigger traps to launch attacks on the enterprise Intranet.



The following describes the common attack modes

Cross-site scripting attacks

Cross-site Scripting (XSS) is an attack that involves running illegal HTML tags or JavaScript in the browser of a registered user of a vulnerable Web Site. Dynamically created HTML sections can hide security holes. In this way, attackers write scripts to trap users running on their own browsers, exposing them to passive attacks if they are not careful. Cross-site scripting attacks can have the following effects. 1. Use false input forms to defraud users of personal information. 2. The script is used to steal the user’s Cookie value, and the victim helps the attacker to send malicious requests without knowing it. 3. Display fake articles or pictures.

HTTP header injection attack

HTTP Header Injection attack is an attack in which the attacker adds any response Header or body by inserting a newline into the response Header field. Passive attack mode. An attack that adds content to a header body is called an HTTP Response SplittingAttack. HTTP header injection attacks have the potential to have the following effects. Set any Cookie information to be redirected to any URL to display any subject (HTTP response truncation attack)

SQL injection attack

SQL Injection Attack SQL Injection is an attack caused by running illegal SQL against the database used by a Web application. This security hazard may cause great threats, sometimes directly lead to the disclosure of personal information and confidential information. Web applications usually use databases. To retrieve, add, or delete data in a database table, SQL statements are used to connect to the database for specific operations. If there is an oversight in the way the SQL statement is called, it is possible to execute an illegal SQL statement that is maliciously injected. SQL injection attacks may have the following effects. 1. Illegally view or tamper with the data in the database. 2

OS command injection attack

OS Command Injection attack means that an illegitimate operating system Command is executed to attack a Web application. Wherever Shell functions can be called there is a risk of attack. Operating system commands can be invoked from a Web application through a Shell. If the Shell is inadvertently called, an illegal OS command inserted can be executed. OS command injection attacks can send commands to the Shell to get the Windows or Linux command line to start a program. That is, OS injection attacks can execute various programs installed on the OS.

Incorrect error message handling

An Error Handling Vulnerability is when a Web application Error message contains information useful to an attacker. The main error messages related to Web applications are shown below. Error messages thrown by Web applications 2. Error messages thrown by systems such as databases Web applications do not need to display detailed error messages on the browsing screen of users. For an attacker, detailed error messages can be a clue to the next attack.

Open redirection

Open Redirect is a function that allows you to Redirect any specified URL. The security vulnerability associated with this feature is that if a specified redirect URL is directed to a malicious Web site, the user will be directed to that Web site. Open redirection Attack Cases The following URL redirection is used as an example to explain open redirection attack cases. This function redirects the ORIGINAL URL after specifying parameters to the URL. Example.com/?redirect=h… The attacker overwrites the parameters specified by the redirect to the corresponding connection for the booby-trapped Web site, as shown below. Example.com/?redirect=h… When the user sees the URL and thinks he is accessing example.com, he is actually redirected to hackr.jp, the specified redirect target. A reliable Web site with redirection enabled is likely to be selected by attackers and used as a springboard for phishing attacks.