See below ↓↓↓↓

preface

This article is 1108 words and takes about 3-4 minutes to read. A deep as the sea into the front !!!!


— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — a line — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

The text start

The front end considers security every time it sends data to the server. There’s no need to worry about things like personal websites, which are rarely visited (like my friend’s). In general, HTML forms are the most likely target for an attacker. This makes sense. When we visit a website, many of its functions need to be logged in before we can use them, including form submission. But most of these security issues don’t come from the HTML form itself; they depend on how the server handles the submitted data.

With that out of the way, let’s talk about some of the more famous attacks.

CSRF and XSS

I’ve heard the brothers of cross-site scripting and site request forgery 20 times. XSS is where an attacker injects a client script into a web page visited by the victim. Attackers can use vulnerabilities in cross-site scripting attacks to bypass access controls such as same-origin policies. To explain, some attackers will set scripts as images, where the SRC attribute is cross-domain. When the image loads, the script executes automatically without you realizing it. CSRF is similar to the former, but their goals are different, CSRF is more ambitious. It wants higher privileges (e.g., administrator privileges) so they can do whatever they want.

It can be summed up in one sentence: AN XSS attack exploits a user’s trust in a website, while a CSRF attack exploits a website’s trust in its users.

So the problem comes, how to solve it? So the problem comes, how to solve it? So the problem comes, how to solve it?

For users, don’t ask too much of them. After all, most of the people who visit the site are not programmers, so they have to deal with the data submitted by users. Try not to display user-supplied HTML content; Also, almost every framework on the market today implements a minimal filter that removes HTML, script tags, iframe tags, and so on from any user-sent data.

SQL injection

SQL injection is a type of attack that attempts to perform operations on a database used by the target web site. Typically, an SQL request is sent and the server is expected to execute it (usually when the application server tries to store data sent by the user). This is one of the main ways to attack websites. The consequences can be dire, ranging from data loss to taking control of the entire website infrastructure through the use of privileged upgrades. This is a very serious threat, so be sure to do some cleanup after storing user-sent data (for example, using mysqli_real_escape_string() on your PHP /mysql infrastructure).

HTTP data header injection and E-mail injection

This type of attack occurs when your application builds HTTP headers or E-mail messages based on user data input on a form. These do not directly damage the server or affect users, but they can cause a deeper problem, such as session hijacking or phishing attacks. This aspect of understanding is less, so introduce so much, interested students can go to understand.

conclusion

To minimize the risk of any attack, never trust anyone, including yourself. Even a trusted user can be hijacked. For example, friends who send you tempting title links in QQ.

All data arriving at the server must be checked and sanitized without exception.

  1. Stay away from potentially dangerous character escapes. How carefully the particular characters should be used depends on the context of the data being used and the server platform being used, but all server-side languages have capabilities.
  2. Limit the amount of data you enter, allowing only necessary data.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — another line — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Blogger level is limited (style needs to be improved), welcome to find fault (manual funny), thank you very much.

References:

Developer.mozilla.org/zh-CN/docs/…