There’s nothing to write down in the first few chapters. I added some safety related stuff at the end.
4 HTTP status code
4.1 Status code Indicates the result of the request returned from the server
Status code | category | The reason the phrase |
---|---|---|
1XX | Informational (Informational status code) | The received request is being processed |
2XX | Success (Success Status code) | The request is successfully processed |
3XX | Redirection (Redirection status code) | Additional action is required to complete the request |
4XX | Client Error (Client Error status code) | The server cannot process the request |
5XX | Server Error | The server failed to process the request |
4.2 2 xx success
200
OK
204
Not Content
206
Partial Content
Responds to a Range request containing the Content of the Range specified by content-range.
4.3 3XX Redirection
301
Moved Permanently
Permanently redirects to the URI prompted by the Location header field302
Found
Temporary redirection.303
See Other
Use a temporary GET request to access another URI.304
Not Modified
Contains responses to any of if-match, if-modified-since, if-none-match, if-range, and if-unmodified-since headers.307
Temporary Redirect
Temporary redirect. POST redirect, I don’t think anyone’s using it.
4.4 4XX Client Errors occur
400
Bad Request
If a syntax error exists in the request packet, the browser treats the status code as 200 OK.401
Unauthorized
Authentication information is required. If yes, the user authentication fails.403
Forbidden
Access is denied.404
Not Found
The requested resource could not be found on.
4.5 5XX Server Error
500
Internal Server Error
An error occurred while executing the request.503
Service Unavailable
The server is temporarily overloaded or is being shut down for maintenance.
5 Web server that collaborates with HTTP
6 HTTP header
6.1 HTTP Header Fields
6.2HTTP/1.1 Generic header Fields
6.2.1 Cache-Control
format
Cache-Control: private, max-age=0, no-cache
Cache request instruction
instruction | parameter | instructions |
---|---|---|
no-cache | Force revalidation to the source server | |
no-store | No content of the request or response is cached | |
Max-age = [seconds] | necessary | The maximum Age value of the response |
Max-stale (= [SEC]) | Can be omitted | Receive an expired response |
Min-fresh = [seconds] | necessary | The expected response within the specified time is still valid |
no-transform | Agents cannot change media types | |
only-if-cached | Fetch resources from the cache | |
cache-extension | New Instruction Token (token) |
Cache response instruction
instruction | parameter | instructions |
---|---|---|
public | There is no | Caching of responses can be provided to any party |
private | Can be omitted | Returns a response only to a specific user |
no-cache | Can be omitted | The cache must be validated before being cached |
no-store | There is no | No content of the request or response is cached |
no-transform | There is no | Agents cannot change media types |
must-revalidate | There is no | Cacheable but must be validated with the source server |
proxy-revalidate | There is no | The intermediate cache server is required to validate the cached response |
Max – age = [s] | necessary | The maximum Age value of the response |
S – maxage = [s] | necessary | The maximum Age value for the public cache server response |
cache-extension | – | New Instruction Token (token) |
no-cacheinstruction
Cache-Control: no-cache
Used in client requests to prevent expired resources from being returned from the cache server.
Cache-Control: no-cache=Location
If the parameter value is specified in the response returned by the server, the cache server cannot use the cache.
No – the store instruction
Cache-Control: no-store
This directive states that the cache server cannot store request or response information locally.
max-ageinstruction
Cache-control: max-age=604800 (unit: seconds)
6.3 Request Header Field
6.3.1 Host
Virtual hosts run on the same IP, so they are distinguished by the header field Host.
Host: www.hackr.jp
6.3.2 If – Match
The server accepts the request only when the if-match field matches the ETag field.
6.4 Response header Field
6.4.1 the Age
Age: 600
6.5 is the header field of the Cookie service
6.5.1 the Set – cookies
Set-Cookie: status=enable; expires=Tue, 05 Jul 2011 07:26:31
When the server is ready to start managing the state of the client, various information is given in advance. Set-cookie field attributes:
- NAME=VALUE The NAME and VALUE assigned to the Cookie (required)
- Expires =DATE Indicates the expiration DATE of the Cookie (defaults to before the browser closes if it is not specified explicitly)
- Path = path Sets the file directory on the server as the appropriate object for cookies (default is the file directory where the document resides if not specified)
- Domain = domain name used as the domain name of the Cookie (if this is not specified, the default is the domain name of the server that created the Cookie)
- Secure sends cookies only for Secure HTTPS communication
- HttpOnly restricts cookies from being accessed by JavaScript scripts
Tactical fix packs for 6.5.2 cookies
Cookie: status=enable
The client request contains a Cookie received from the server telling the server that it wants state management support.
7 HTTPS
7.1 Communication Encryption
Encrypts HTTP traffic using the Secure Socket Layer (SSL) or Transport Layer Security (TLS) protocol.
7.2 HTTP+ Encryption + Authentication + Integrity Protection =HTTPS
HTTPS is HTTP in an SSL shell.
7.2.1 HTTPS CA Certificate and Encrypted Communication Process
Because public key encryption is slow, hybrid encryption is adopted. Public key encryption is used to transmit the shared key first, and then the shared key is used to encrypt communication.
9 Add protocols based on HTTP
9.3 the WebSocket
To implement WebSocket communication, after an HTTP connection is established, you need to complete a “Handshaking” step.
- Shake hands · Request
The Upgrade header field of HTTP is used to inform the server that the communication protocol has changed in order to achieve the purpose of handshake.
GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Origin: example.com Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13
The sec-websocket-key field records the essential Key values in the handshake process. The sec-websocket-protocol field records the subprotocol used.
- Handshake · Response
HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Protocol: chat
Sec-WebSocket-AcceptThe value of the field is determined by the handshake requestSec-WebSocket-KeyGenerated by the field value of. After a successful handshake to confirm the WebSocket connection, HTTP data frames are no longer used in favor of websocket-independent data frames.
HTTP / 2.0 9.4
HTTP/2 is the first update to the HTTP protocol since the release of HTTP1.1 in 1999 and is based on the SPDY protocol.
9.4.1 SPDY protocol
SPDY is a term of Speedy, meaning ‘faster’. It is an application layer protocol based on TCP protocol developed by Google. The goal is to optimize the performance of the HTTP protocol to reduce load times and improve security of web pages through compression, multiplexing, and prioritization. The core idea of SPDY protocol is to minimize the number of TCP connections. SPDY is an enhancement to HTTP.
9.4.2 Disadvantages of http1.x
- HTTP/1.0 allows only one request to be made at a time over one TCP connection, and HTTP/1.1 uses pipelined-line technology that can only partially handle request concurrency. Queue header blocking is still a problem, so clients often establish multiple connections to reduce latency when they need to make multiple requests.
- A one-way request can only be initiated by the client.
- The information on the packet header is redundant.
- Data is not compressed.
9.4.2.1 HTTP/1.1 Queue Header Is Blocked
Http1. x uses a keep-alive Connection to send multiple HTTP requests over a TCP request.
- Pipelining: complete serial execution, request -> response -> request -> response… , the latter request must be sent after the previous response. Cause congestion.
- Non-pipelining: more problems, basically no use.
Solution: The browser uses 6-8 TCP connections for a domain name and concurrent HTTP requests.
9.4.3 HTTP 2.0 features
9.4.3.1 Binary Framing
Change from string transmission to binary transmission.To keep HTTP unaffected, you need to add a binary framing layer between the application layer (HTTP2.0) and the transport layer (TCP or UDP). At the binary framing layer, HTTP2.0 breaks all transmitted information into smaller messages and frames and encodes them in a binary format, where the http1.x header is encapsulated in the Headers frame and the Request Body in the Data frame.
9.4.3.2 Header Compression
HPACK (HTTP2 header compression algorithm) compression is used to reduce the size and caching of existing content to reduce repeated transfers.
9.4.3.3 Multiplexing
Because browsers have limits on the number of requests under the same domain, blocking queues can occur.
HTTP/2 introduces the concept of binary data frames and streams, in which frames identify data sequentially, so that when the browser receives the data, it can merge the data sequentially without losing the merged data. Again, because of sequences, the server can transfer data in parallel.
HTTP/2 is stream-based for all requests under the same domain name, which means that no matter how many files are accessed from the same domain name, only one connection is established. Also, Apache’s maximum number of connections is 300, because with this new feature, the maximum number of concurrent connections can be increased to 300, which is a six-fold increase.
9.4.3.4 Request Priority
By dividing HTTP messages into many individual frames, you can further optimize performance by optimizing the interleaving and transmission order of these frames.
9.4.3.5 Server Push
The server can send multiple responses to a client request. The server pushes resources to the client without explicit request from the client.
11 Web Attack Technologies
XSS cross-site scripting attacks
XSS (Cross-Site Scripting, XSS), the principle of XSS is that malicious attackers insert malicious executable Web Scripting code into Web pages.
Non-persistent XSS
Also called reflex XSS vulnerability, it is usually attacked by adding malicious code parameters to the URL.
How to prevent:
- Try not to
URL
.document.referrer
.document.forms
Wait for this DOM API to get the data directly rendered. - Try not to use
eval
.new Function()
.document.write()
.document.writeln()
.window.setInterval()
.window.setTimeout()
.innerHTML
.document.creteElement()
Methods such as executable string. - The front-end rendering will need to do escape encoding for any field.
A persistent XSS
Persistent XSS vulnerability, also known as storaged XSS vulnerability, generally exists in interactive functions such as Form submission. Hackers take advantage of XSS vulnerability to submit content to the database for persistent storage through normal functions. When the front end page obtains the injected code read from the database by the back end, it just renders it for execution. How to prevent:
- The backend will uniformly escape all fields before entering the library.
- The back end uniformly escapes the output data to the front end.
- The front-end needs to escape any field when rendering the DOM of the page.
Character set-based XSS
Bypassing escape processing through other character sets. How to prevent:
- Remember to specify
<meta charset="utf-8">
- In XML, not only must the character set be utF-8, but the tag must be closed
Cross-site XSS based on Flash
AS scripts can accept user input and manipulate cookies, but FLASH is dead…
Unauthenticated jump XSS
There are some scenarios where the backend needs to perform a 302 jump on an incoming URL parameter that is ready to jump, possibly with some sensitive cookie information from the user.
CSRF cross-site request forgery
Cross-site Request Forgery (CSRF) : cross-site Request Forgery attack.
CSRF principle
CSRF prevention
How to prevent:
- Submit the verification code.
- Validate the HTTP Referer field. This field records the source address of the HTTP request.
- Token authentication. Add a server-side generated random token as a parameter to the HTTP request and validate it on the server side.
- Add the token and validate with your own attributes in the HTTP header.
SQL injection
Principles of SQL Injection
SQL injection attacks often fail to filter user input, such as Form forms, causing the server to execute unexpected logic after concatenating parameters into SQL statements.
SQL injection prevention
- The input content is escaped and filtered.
- You are advised to use the parameterized query interface provided by the database for all query statements.
- Strictly restrict the operation rights of the Web application database.
- Do not return verbose error messages from the server.
Command line injection
The principle is similar to SQL injection.
DDoS attack
DDoS, also known as Distributed Denial of Service, overloads resources with a large number of requests, making services unavailable. DDos attacks are classified into network layer attacks and application layer attacks, and fast traffic attacks and slow traffic attacks in terms of attack methods
The network layer DDoS
SYN Flood attack
SYN flood attacks mainly use the TCP three-way handshake. In the TCP three-way handshake, the two connected parties send SYN, SYN + ACK, and ACK packets. When the attacker constructs source IP addresses randomly to send SYN packets, In this case, the server tries to send a SYN + ACK packet again and waits for at least 30 seconds. As a result, the resource saturation service is unavailable. This attack is a slow DDoS attack.
ACK Flood attack
After the TCP connection is established, all the transmitted TCP packets carry THE ACK flag bit. When receiving a packet with the ACK flag bit, the host needs to check whether the connection quad represented by the packet exists. If so, check whether the state represented by the packet is valid, and then pass the packet to the application layer. If the packet is found to be invalid, for example, the port to which the packet is destined is not enabled on the host, the protocol stack of the host operating system responds to the RST packet to inform the peer that the port does not exist.
UDP Flood attack
As UDP is a connectionless protocol, an attacker can forge a large number of source IP addresses to send UDP packets. This type of UDP flood attack is a large-traffic attack. In normal applications, the bidirectional traffic of UDP packets is almost equal. Therefore, the attacker consumes his own resources while consuming the other’s.
The ICMP Flood attack
ICMP Flood attacks are massive traffic attacks. Abnormal ICMP packets are continuously sent. As a result, the target bandwidth is occupied and resources are consumed. Ping is now disabled on many servers (ICMP packets can be blocked on the firewall), so this attack is outdated.
Network layer DDoS defense
DDoS attacks at the network layer are essentially undefendable. What we can do is to constantly optimize the network architecture deployed by the service itself and improve network bandwidth. Of course, do the following things to help mitigate the impact of network layer DDoS attacks:
- Optimize the network architecture and use load balancing.
- Make sure that the system files on the server are up to date and that system patches are up to date.
- Add an anti-ddos device to clean traffic.
- Limit the number of SYN half-connections that can be opened at the same time and shorten the SYN half-connections Timeout.
- Limit the frequency of single IP requests.
- Defense Settings such as firewalls prohibit ICMP packets.
- Strictly restrict the access to external servers.
- When running a port mapper or a port scanner, carefully check privileged and non-privileged ports.
- Shut down unnecessary services.
- Carefully check the logs of network devices and host/server systems. Any log leak or time change could mean the machine is under attack.
- Restrict network file sharing outside the firewall. This will give hackers the opportunity to intercept system files, host information exposed to hackers, is undoubtedly to give the other party the opportunity to invade.
- Add money pile machine..
- Report to the police.
The application layer DDoS
DDoS attacks at the application layer occur after the TCP handshake is established, not at the network layer. The application layer attacks are ever-changing, and the goal is to use up your bandwidth in a network application.
CC attack
The principle of CC attacks is to continuously launch abnormal requests for pages that consume large resources, resulting in resource exhaustion.
DNS Flood
The DNS Flood attack sends a large number of non-existent domain name resolution requests to the attacked server. As the DNS server searches for domain names one by one, normal DNS domain name resolution times out due to heavy load.
HTTP slow connection attack
For HTTP protocol, first establish HTTP connection, set a large conetnt-length, send a few bytes each time, let the server always think that the HTTP header is not completed, so that more connections will soon appear connection exhaustion.
Application-layer DDoS defense
- Determine user-Agent fields (unreliable because they can be constructed arbitrarily)
- Limit the frequency of access for IP + cookies (since cookies can be changed, IP can use proxies, or broilers, which are also unreliable)
- Disable the maximum number of server connections and properly configure the middleware to mitigate DDoS attacks.
- Add a captcha to the request, such as when there is a database operation in the request.
- When writing the code, optimize as far as possible, and make reasonable use of caching technology, reduce the database read operation.
- Add money pile machine..
- Report to the police.
Traffic was hijacked
DNS hijacking
DNS hijacking, also known as domain name hijacking, resolves a domain name to an incorrect IPI address. Generally because small operators give a problem, or computer poisoning.
HTTP hijacked
HTTP hijacking is mainly when users visit a site will pass through the operator’s network, and illegal operators and black collusion can intercept HTTP request returned content, and can tamper with the content, and then returned to the user. This can be partially avoided by using HTTPS or setting content-security-policy, for example:
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">
Copy the code
The resources
- Illustrated HTTP
- Summary of common Web security attacks and defenses