common attacks on the web

common attacks on the web

web attack definition

Web attack (WebAttack) is the behavior of attacking the user's online behavior or the website server and other equipment

  • General attack methods: implant malicious code, modify website permissions, obtain website user privacy information, etc.
  • Common web attack methods:
    • XSS (Cross Site Scripting) cross-site scripting attack
    • CSRF (Cross-site request forgery) cross-site request forgery
    • SQL injection attack

XSS

XSS, cross-site scripting attack, allows attackers to insert malicious code into pages served to other users

XSSInvolves three parties , namely attacker , client and Webapplication

XSSThe target of the attack is to steal sensitive information stored on the client cookieor used by other websites to identify the client . Once the legitimate user's information is obtained, the attacker can even interact with the website as a legitimate user

  • case:

    A search page that urldetermines the content of keywords based on parameters

    <input type="text" value="<%= getParameter("keyword") %>">
    <button>搜索</button>
    <div>
      您搜索的关键词是:<%= getParameter("keyword") %>
    </div>
    

    When the attacker enters:, "><script>alert('XSS');</script>the following code will be obtained

    <input type="text" value=""><script>alert('XSS');</script>">
    <button>搜索</button>
    <div>
      您搜索的关键词是:"><script>alert('XSS');</script>
    </div>
    

    The browser cannot tell that alert('XSS');is malicious code, so it executes it;

    When alert('XSS')part of the js code is replaced by obtaining user login information and sending it to the attacker's own server, the attacker successfully obtains the user's user information and completes the XSS attack.

  • According to the source of the attack, XSSthe attack can be divided into:

    • storage type
    • reflective
    • DOM type

Stored XSS

Stored XSS attack steps:

  1. The attacker submits malicious code into the database of the targeted website
  2. When the user opens the target website, the website server retrieves the malicious code from the database, splices it in HTML and returns it to the browser
  3. The user browser parses and executes the response after receiving the response, and the malicious code mixed in it is also executed
  4. Malicious code steals user data and sends it to the attacker's website, or pretends to be the user's behavior, calling the target website interface to perform the operation specified by the attacker

This kind of attack is common in website functions with user saved data, such as forum posts, product reviews, user private messages, etc.

Reflected XSS

The attack steps of reflected XSS:

  1. The attacker constructs a special URL containing malicious code
  2. When a user opens a URL with malicious code, the website server takes out the malicious code from the URL, splicing it in HTML and returning it to the browser
  3. The user browser parses and executes the response after receiving the response, and the malicious code mixed in it is also executed
  4. Malicious code steals user data and sends it to the attacker's website, or pretends to be the user's behavior, calling the target website interface to perform the operation specified by the attacker

The difference between reflected XSS and stored XSS is: the malicious code of stored XSS is stored in the database, and the malicious code of reflected XSS is stored in the URL.

Reflected XSS vulnerabilities are common in functions that pass parameters through URLs, such as website search and redirection.

Since users need to actively open malicious URLs to take effect, attackers often combine multiple means to induce users to click.

The content of POST can also trigger reflective XSS, but its trigger conditions are relatively harsh (you need to construct a form submission page and guide users to click), so it is very rare

DOM-type XSS

DOM type XSS attack steps:

  1. The attacker constructs a special URL containing malicious code
  2. User opens URL with malicious code
  3. After the user's browser receives the response, it parses and executes it, and the front-end JavaScript takes out the malicious code in the URL and executes it
  4. Malicious code steals user data and sends it to the attacker's website, or pretends to be the user's behavior, calling the target website interface to perform the operation specified by the attacker

The difference between DOM-type XSS and the previous two types of XSS: In a DOM-type XSS attack, the removal and execution of malicious code is completed by the browser, which is a security vulnerability of the front-end JavaScript itself, while the other two types of XSS are both server-side security vulnerabilities

XSS prevention

Two elements of xss attack:

  • Attacker submits malicious code
  • The browser executes malicious code

prevention:

Assumption: The front-end restricts where users can submit malicious code: such as verifying user input content, filtering code characters, < > / ""etc.

Problem: If an attacker bypasses the front-end and directly writes data to the back-end, the back-end will filter and store it in the database. When it is returned to the front-end, the content will be displayed in different ways in different places

Example:

​ A normal user enters 5 < 7this content, and before writing it into the database, it is escaped and becomes5 &lt; 7

  • When 5 &lt; 7used as HTML, it can be displayed normally as 5 < 7
  • When returning 5 &lt; 7through Ajax and then assigning it to a JavaScript variable, the character string obtained by the front end is the escaped character. This content cannot be directly used for the display of templates such as Vue, nor can it be directly used for content length calculation. Cannot be used for headers, alerts, etc.

Therefore, filtering is not the best way to prevent xss; nor is it the most reliable way.

The following is to prevent the browser from executing malicious code:

  1. Be especially careful when using .innerHTML, .outerHTML, document.write()and don't insert untrusted data as HTML into the page, but try to use .textContent, , .setAttribute()etc.

  2. If you use Vue/Reactthe technology stack and don't use v-htmlthe / dangerouslySetInnerHTMLfunction, you can avoid the hidden dangers of XSS in the front render- innerHTMLend outerHTMLstage

  3. Inline event listeners in the DOM, such as location, onclick, onerror, onload, onmouseoveretc., attributes<a> of tags , and JavaScript’s , , etc., can run strings as codes. If untrustworthy data is concatenated into strings and passed to these APIs, it is easy to cause security risks, please be sure to avoidhrefeval()setTimeout()setInterval()

<!-- 链接内包含恶意代码 -->
<a href="UNTRUSTED">1</a>

<script>
// setTimeout()/setInterval() 中调用恶意代码
setTimeout("UNTRUSTED")
setInterval("UNTRUSTED")

// location 调用恶意代码
location.href = 'UNTRUSTED'

// eval() 中调用恶意代码
eval("UNTRUSTED")

CSRF

CSRF (Cross-site request forgery) cross-site request forgery: the attacker induces the victim to enter a third-party website, and in the third-party website, sends a cross-site request to the attacked website

Use the registration credentials obtained by the victim on the attacked website to bypass the background user verification and achieve the purpose of impersonating a user to perform an operation on the attacked website

A typical CSRF attack has the following process:

  • Victim logs into a.com and retains login credentials (Cookie)
  • The attacker lures the victim to visit b.com
  • b.com sends a request to a.com: a.com/act=xx. The browser will carry the cookie of a.com by default
  • After a.com receives the request, it verifies the request and confirms that it is the victim's credentials, mistakenly thinking that it is the request sent by the victim himself
  • a.com performed act=xx on behalf of the victim
  • The attack is completed, the attacker pretends to be the victim without the victim's knowledge, and makes a.com perform the operation defined by himself

csrfIt can be getrequested, that is, after the visited imgpage, the browser automatically accesses the target address and sends the request

Similarly, you can also set up an auto-submitted form to send posta request, as follows:

<form action="http://bank.example/withdraw" method=POST>    <input type="hidden" name="account" value="xiaoming" />    <input type="hidden" name="amount" value="10000" />    
 <input type="hidden" name="for" value="hacker" />
</form>
<script> document.forms[0].submit(); </script> 

After visiting the page, the form will be automatically submitted, which is equivalent to simulating the user to complete an POSToperation

There is also a alabel that requires the user to click on the link to trigger

After visiting the page, the form will be automatically submitted, which is equivalent to simulating the user to complete a POST operation

<a href="http://test.com/csrf/withdraw.php?amount=1000&for=hacker" taget="_blank">    重磅消息!!<a/>

Features of CSRF

  • Attacks are generally launched on third-party websites, not the attacked website. A compromised website cannot prevent the attack from happening
  • The attack uses the victim's login credentials on the attacked website to impersonate the victim to submit an operation; instead of directly stealing data
  • The attacker cannot obtain the victim's login credentials during the whole process, it is just "false use"
  • Cross-site requests can be made in various ways: image URL, hyperlink, CORS, Form submission, etc. Some request methods can be directly embedded in third-party forums and articles, making it difficult to track

Prevention of CSRF

CSRF is usually initiated from a third-party website. The attacked website cannot prevent the attack from happening. It can only improve the security by enhancing the protection ability of its own website against CSRF.

The common solutions for prevention csrfare as follows:

  • Block access from unknown foreign domains

    • homology detection
    • Samesite Cookie
  • Information that requires this field to be attached when submitting

    • CSRF Token
    • Double Cookie Authentication

Here we mainly talk about tokenthis form, the process is as follows:

  • When the user opens the page, the server needs to generate a Token for the user
  • For GET requests, Token will be appended to the request address. For POST requests, add at the end of the form
<input type=”hidden” name=”csrftoken” value=”tokenvalue”/>
  • When the user gets the Token from the client and submits it to the server again, the server needs to judge the validity of the Token

SQL

Sql injection attack is an attack by inserting malicious Sqlquery or adding statement into the input parameters of the application, and then Sqlparsing and executing it on the background server

The flow is as follows:

  • Find the injection point of the SQL vulnerability
  • Determine the type and version of the database
  • Guess usernames and passwords
  • Use tools to find the web background management entry
  • invasion and sabotage

Prevention methods are as follows:

  • Strictly check the type and format of input variables
  • Filter and escape special characters
  • Use a Web Application Firewall for Web applications accessing databases

Summarize

Common attacks:

  • XSS cross-site scripting attack

    • Storage type, malicious code exists in the server, server security holes, use V-HTML, innerHTML, outerHTML, document.write carefully to prevent
    • Reflective, malicious code exists in url, l browser parses and executes malicious code, server security vulnerability, the front end prevents it in the render stage
    • dom type, malicious code exists in url, run malicious string as code, front-end security vulnerability
  • CSRF cross-domain fake request attack

    • Features:
      • The attack is launched on the third website, and the attacked website cannot prevent the attack
      • Attackers impersonate user login credentials to operate on the website, not directly steal data
      • During the entire attack process, the user login credentials cannot be obtained, but the identity is only "fake"
      • There are many methods of cross-site requests, which are difficult to track
    • prevention:
      • Same Origin Policy
      • Samesite Cookie
      • double token
  • SQL injection

    • server vulnerability
    • Use vulnerabilities to inject malicious sql for damage

    prevention

    • Strictly check the type and format of input variables
    • Filter and escape special characters
    • Use a Web Application Firewall for Web applications accessing databases

    The above content is only a summary of personal learning, if there are any mistakes, please point out

Guess you like

Origin blog.csdn.net/qq_44900902/article/details/120009134