This is from the training I did before. I have deleted some relevant information and referred to a lot of materials (
List of resources), thank you, 😘

Web front-end security covers a lot of content, which is also an important part that must be paid attention to in front-end project development. In the development of Web site, if there is no good security protection measures, not only may because of the malicious behavior of attackers affect the page function of the site, disclose the privacy of users’ voting rights, but also may directly bring users economic losses.

Of course, security is not just about the front end. This section mainly introduces some security knowledge related to the front end.

XSS

A Cross Site Script (XSS) attack is an attack in which hackers tamper with web pages through “HTML injection” and insert malicious scripts to gain control of users’ browsers while they browse.

The essence of XSS is “HTML injection,” where the user’s data is executed as part of THE HTML code, resulting in new semantics.

XSS can be divided into three categories based on where the attack script is introduced:

Reflective XSS

Nonpersistent, reflecting user input data back to the browser, through the back end, not through the database. A hacker needs to trick a user into “clicking” on a malicious link in order to succeed.

Type stored XSS

Persistence, code stored in the database, through the back end, through the database. For example, in the case of personal information or published articles, if the code, if not filtered or filtered loosely, then the code will be stored in the database and triggered when the user accesses the page.

For example, if you enter a user’s signature on a form, the front end will display the signature content directly on the page. If XSS is not performed, suppose you enter:

<script>alert(1)</script>Copy the code

When the browser displays the user’s signature, it may trigger a pop-up. Note that the script here is just a demonstration; in the event of an attack, the script might perform various actions, such as fetching cookies or sending all local storage somewhere, opening an illegal URL, and so on.

DOM Based XSS

XSS is formed by modifying the DOM nodes of the page without going through the back end.

For example, the front-end renders the page DOM directly by fetching the URL parameter:

http://localhost:8080/dvwa/vulnerabilities/xss_d/?default=English<script>alert(1)</script>

Page popup:

XSS attack Challenge. Xss-game.appspot.com

Solution: gist.github.com/pbssubhash/…

Click preview

Defense way

Generally, HTML character encodings are escaped to guard against XSS, such as:

function HTMLEncode(str) {
    let s;
    if (str.length === 0) return "";
    s = str.replace(/&/g, "&gt;");
    s = s.replace(/</g, "&lt;");
    s = s.replace(/>/g, "&gt;");
    s = s.replace(/ /g, "&nbsp;");
    s = s.replace(/'/g, "'"); s = s.replace(/"/g, "&quot;");
    s = s.replace(/\n/g, "<br>");
    return s;
}

function HTMLDecode(str) {
    let s;
    if (str.length === 0) return ""; s = str.replace(/&gt; /g,"&"); s = s.replace(/&lt; /g,"<"); s = s.replace(/&gt; /g,">"); s = s.replace(/&nbsp; /g,"");
    s = s.replace(/'/g, "'"); s = s.replace(/" /g, "\"");
    s = s.replace(/<br>/g, "\n");
    return s;
}Copy the code

But there are many ways to bypass filtering, such as:

The data protocol executes javascript:

<a href=data:text/html; base64,PHNjcmlwdD5hbGVydCgzKTwvc2NyaXB0Pg==>Copy the code

Jsfuck:

+ [] [] [] [(!) [+ []] + [[! []] + [] [[]]) [+, + + + [] [] []] + (! [] + []) [! + [] + + []] + (!! [] + []) [[]] + + (!! [] + []) [! + [] +, + + []! + []] + (!! [] + []) [+! + [[]]] ([[] (! [] + []) [+ []] + [! []] + [] ([[]]) [+, + + + [] [] []] + (! [] + []) [! + [] + + []] + (!! [] + []) [[]] + + (!! [] + []) [! + [] +, + + []! + []] + (!!!!! [] + []) [+! + []]] + []) [! + [] +, + + []! + []] + (!! [] + [] [(! [] + []) [+ []] + [[! []] + [] [[]]) [+, + + + [] [] []] + (! [] + []) [! + [] + + []] + (!!!!! [] + + [] [] []) + (!! [] + []) [! + [] +, + + []! + []] + (!! [] + []) [+! + []]]], [+, + + + [] [] []] + [] ([[]] + []) [+! + []] + (! [] + []) [! + [] +, + + []! + []] + (!!!!! [] + + [] [] []) + (!! [] + []) [+! + []] + [] ([[]] + []) (+ + [] [] [] [(! [] + []) [+ []] + [[! []] + [] [[]]) [+, + + + [] [] []] + (! [] + []) [! + [] + + []] + (!!!!! [] + + [] [] []) + (!! [] + []) [! + [] +, + + []! + []] + (!! [] + []) [+! + []]] + []) [! + [] +, + + []! + []] + (!! [] + []) [[]] + + (!! [] + [] [(! [] + []) [+ []] + [[! []] + [], [[]]) [+. + + + [] [] []] + (! [] + []) [! + [] + + []] + (!! [] + []) [[]] + + (!! [] + []) [! + [] +, + + []! + []] + (!! [] + []) [+! + []]]) [+. + + + [] [] []] + (! ! [] + []) [+! + []]] ((! [] + []) [+! + []] + (! [] + []) [! + [] + + []] + (!!!!! [] + []) [! + [] +, + + []! + []] + (!!!!! [] + []) [+! + []] + (!!!!! [] + + [] [] []) + (! (! [[] + [] [] []) + + + [] [] [! []] + [] ([[]]) [+, + + + [] [] []] + (! [] + []) [! + [] + + []] + (!! [] + []) [[]] + + (!! [] + []) [! + [] +, + + []! + []] + (!!!!! [] + []) [+! + []]]) [! + [] +, + + + [] [] []] + [+! + []] + (!!!!! (! [[] + [] [] []) + + + [] [] [! []] + [] ([[]]) [+, + + + [] [] []] + (! [] + []) [! + [] + + []] + (!! [] + []) [[]] + + (!! [] + []) [! + [] +, + + []! + []] + (!!!!! [] + []) [+! + []]]) [! + [] +, + + + [] [] []]) ()Copy the code

Deeper into the game: prompt. Ml /

You are advised to use mature libraries, such as github.com/leizongmin/…

Protect the user’s Cookie, plus HttpOnly attribute, plus this attribute’s Cookie field, JS is unable to read and write.

The front and back ends must be filtered, and the user input content must be displayed carefully.

SQL injection

SQL injection refers to the injection of SQL statements into the input string. If the application trusts the user’s input and does not filter the input string, the injected SQL statements will be mistaken by the database for normal SQL statements and executed.

For example, back-end code:

$un = @$_POST['un'];
$pw = @$_POST['pw'];

// ...

$sql = "select * from user where un='$un' and pw='$pw'";Copy the code

For front-end input, we assign UN to admin and PW to ‘or ‘1’=’1. The entire SQL statement becomes:

select * from user where un='admin' and pw=' ' or '1'='1'Copy the code

You’ve successfully circumvented authentication.

SQL injection is too well known to be covered here.

CSRF

CSRF (Cross-site request Forgery), also known as One Click Attack or Session Riding, is a malicious exploitation of a website. XSS exploits trusted users within the site, while CSRF exploits trusted web sites by masquerading requests from trusted users.

For example, there is A CSRF vulnerability in A bank site. User A transfers 2000 yuan to user B and sends A request to the bank after the transfer operation: www.bank.com/money?use.. … , then user A will transfer his 2000 yuan to user B’s account. When sending the request to the bank server, the server will verify whether the request is A valid session, and user A must confirm login to verify the request.

If A malicious user C wants to transfer user A’s money to his own account, he can construct www.bank.com/money?use.. … This request, however, can only take effect if issued by user A. At this time, malicious user C can build A website and write the following code in the website: < img SRC = “http://www.bank.com/money?user=A&num=2000&transfer=C” > after the induction of A user to access your site, when A visit to the site, the site will send the URL in the img tags to bank server, In addition to this request, user A’s cookie will also be sent to the server. If the session between user A’s browser and the bank does not expire at this time, user A will transfer the money to C without user A’s knowledge.

CSRF is generally used in the following scenarios:

1. Attack the website administrator: trick the administrator to click the link with the vulnerability, and perform the operation of adding and deleting the website management account, so as to infiltrate the website shell permission.

Discuz! X2.5, X3, and X3.1 can delete administrator accounts using CSRF

Post insert Discuz! Code in which uIDArray can be modified to delete multiple specified users:

[img]admin.php? frame=no&action=members&operation=clean&submit=1&uidarray=1&confirmed=yes[/img]Copy the code

2. Modify user accounts and data on the victim websites: reset account passwords, change mailbox binding, modify personal data and personal Settings, delete articles and posts published by users, etc.

Meilishuo.com CSRF reset the password of any user account (merchant account certificate has been obtained)

3. Account hijacking: there is no authentication of the original password and no token authentication when changing the password. Just send a link to change the password. Or send a link to change the bound mailbox and reset the password.

Wechat public platform CSRF can lead to the hijacking of public accounts

4. Spread the CSRF worm to carry out large-scale attacks: such attacks generally occur in SNS sites, batch following, tweeting and changing personal information.

Sina Weibo CSRF points I link to microblogging (worm)

5. Use CSRF to drag the library.

Discuz can CSRF off pants

6. Use other vulnerabilities for a one-two punch attack.

Defense way

1. Use verification code:

CSRF attacks are usually launched without the knowledge of the victims. Verification codes can effectively prevent attacks. However, entering a verification code for each request will affect user experience, so CSRF is usually used only for user login and registration, and for some specific business scenarios, such as bank transfer. How captchas are used depends on the business and scenario.

2. Verify HTTP Referer:

The referer field in the HTTP header records the source address of the request, such as www.test.com after clicking a link from www.test.com to m.test.com. When attacking the victim, the attacker constructs his own malicious script on his own server to trick the victim into clicking, so the referer value at this time is the attacker’s OWN URL address. It can be seen from the above that CSRF attacks are initiated across domains, so the server can effectively defend against such attacks by verifying whether the referer field belongs to a secure and reliable domain name to a certain extent.

But such methods are not foolproof, and hackers can tamper with referer values in older, buggy browsers. In another case, CSRF attacks with XSS, so cross-domain initiation is not required and referer verification can be bypassed.

3. Use tokens

When a user logs in for the first time, the client will request the server to log in through the user name and password. After receiving the request, the server will verify the user name and password sent by the client. If the verification is successful, the server will issue a token to the client and put the token into the session or packet. After receiving the token, the client stores the token to the local PC. Each time the client requests the server, the token will be returned only after the server authenticates the request. Otherwise, an error will be reported.

The prerequisite for a successful CSRF attack is that the attacker can completely forge all the requests of the victim, and the authentication information in the request is in the cookie. The hacker can complete the attack by using the user’s cookie to pass the security verification. Knowing this, to prevent CSRF attacks, you need to place information in the HTTP request that a hacker cannot forge, and that information cannot exist in a cookie or it will be invalid. The biggest characteristic of token is randomness, unpredictability, and does not exist in cookies.

Finally, note that if XSS vulnerabilities exist in the same domain, then this defense using token will be meaningless.

SSRF

Many Web applications provide the ability to fetch data from other servers. Using user-specified urls, web applications can get images, download files, read file contents, and so on. This feature, if used maliciously, can be used to attack remote and local servers using a compromised Web application as a proxy. This form of attack is called Server Side Request Forgery (SSRF).

For example:

<? php$url = @$_GET['url'];
if($url) {
    $ch = curl_init();
    curl_setopt($ch, CURLOPT_URL, $url);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
    curl_setopt($ch, CURLOPT_HEADER, 0);
    curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
    curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
    $co = curl_exec($ch);
    curl_close($ch);
    echo $co;
}Copy the code

This code reads the URL parameter from the URL, accesses the URL resource that the URL parameter points to, and displays the resource on the page.

Let’s go to localhost/ssrf.php? Url=www.baidu.com:

The hole can also be used to access the local resources, we will visit file:///C:/Windows/win.ini

The following business scenarios are prone to this vulnerability:

  • The app takes an image from a user-specified URL, saves it on a hard disk with a random name, and presents it to the user.
  • The application retrieves data (files or HTML) from a user-specified URL. This function establishes a TCP connection with the server using the socket and transmits raw data.
  • According to the URL provided by the user, the application captures the user’s Web site and automatically generates a mobile Wap site.
  • The application provides the speed measurement function, which can access the target site according to the URL provided by the user to obtain the access speed at the corresponding latitude and longitude.

For example, a SSRF of Youdao Translation can connect to the NetEase Intranet

Defense way

  • It is easier to filter the returned information and verify the remote server’s response to the request. If a Web application obtains a certain type of file, it can verify that the returned information meets the criteria before presenting the results to the user.
  • Unified error information prevents users from judging the port status of the remote server based on error information.
  • Restrict requests to common HTTP ports, such as 80, 443, 8080, and 8090.
  • Blacklist Intranet IP addresses to prevent applications from being used to obtain Intranet data and attack the Intranet.
  • Disable unnecessary protocols. Only HTTP and HTTPS requests are allowed. Prevents problems like file://, gopher://, and ftp://.

hijacked

Most of the time, our website is not directly accessed to our server, the middle will go through many layers of proxy, if in a certain link, the data is intercepted by the hijacker of the intermediate proxy layer, they can obtain the password of the user using your website and other confidential data.

HTTP hijacked

HTTP hijacked refers to, in the purpose of the user’s browser and visit the established network data transmission channel between the server monitoring specific data from the gateway or firewall layer information, when to meet certain conditions, will be inserted in the normal packet becomes an attacker to design or modify the network packets, the goal is to make data on the user’s browser to explain the “wrong”, Or display a promotional AD on the user’s browser interface in the form of a new pop-up window or display a piece of other content directly.

In this case, the IP address of the source website requested by the user and the content and script loaded by the website are all correct. However, the content request may be hijacked and modified by the ISP (Internet Service Provider) during the process of returning the website content request. Finally, add and display some ads and other content information on the browser page.

It may also be that we even have some strange wifi in various restaurants. If the wifi is the hotspot wifi established by the hacker, then the hacker can intercept all the data sent and received by the user. 315 has demonstrated this scenario before.

There is often no way for web developers to prevent these situations by modifying the site code and procedures. The only practical way to prevent request hijacking is to use the HTTPS protocol to access the target website whenever possible. And try not to censor the Internet.

DNS hijacking

DNS hijacking, often referred to as the attacker seized the DNS server, by some means to obtain a domain name analytical record control, and then modify the domain name resolution as a result, lead to the user access to the domain address by the original IP address to the modified to specify the IP address of the phenomenon, the result is to make the correct url cannot parse or be parsed IP points to another web site, To achieve the purpose of obtaining user information or destroying the normal service of the original website. DNS hijacking is implemented by tampering with domain name resolution records on the DNS server to return incorrect DNS query results to users.

DNS hijacking does not have a good solution, try not to ceng the network, website use HTTPS protocol as far as possible.

Click on the hijacked

ClickJacking is a form of visual deception. The attacker uses a transparent, invisible IFrame to overlay a web page and then trick the user into doing something on the page, where the user unknowingly clicks on the transparent IFrame page. By adjusting the position of the iframe page, you can trick the user into hitting some functional buttons on the iframe page.

The danger of clickjacking is that the attack exploits the victim’s user identity to do something without his or her knowledge. Forcing users to follow a Weibo account might seem bearable, but deleting an important file or stealing sensitive information is much more damaging.

The main defense against clickjacking is to set the HTTP request header (x-frame-options), the X-frame-options HTTP response header that indicates whether the browser should load a page in an IFrame. Web sites can prevent clickjacking by setting X-frame-options to prevent pages within the site from being embedded by other pages.

It is also possible to disable iframe nesting by writing JavaScript, but it can be easily circumvented:

/ / -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - / / prevent sites by other web pages as embedded iframe / / -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -if(self ! = top) { top.location.href = self.location.href; }Copy the code

Code execution

Because developers write source code without filtering the entry of special functions that can be executed in the code, clients can submit malicious construction statements for execution by the server. In the command injection attack, the Web server does not filter functions such as system, eval and exec, which is the main reason for the success of this vulnerability attack.

For example:

<? php // code-exe.php:$code= @$_GET['code']; //http://localhost/subject/code-exe.php? code=echo "<center>Payload:".$code."<br/>Result:</center>
eval($code);Copy the code

Visit http://localhost/code-exe.php… So you can see PHP INFO.

Remote code execution of python template of a site in Baidu

Insecure third party dependencies

According to statistics, nearly 80% of the code of an application actually comes from third-party components, dependent libraries, etc., while the application’s own code actually only accounts for about 20%. Whether it is back-end server applications or front-end application development, most of the time we are using development frameworks and various class libraries for rapid development.

For example, jQuery has several known security vulnerabilities, such as jQuery Issue 2432, that make applications vulnerable to XSS attacks. Node.js also has some known security vulnerabilities, such as CVE-2017-11499, which can lead to DoS attacks on front-end applications. In addition, front-end applications, in addition to the front-end development framework used, often rely on a number of Node component packages, which may also have security vulnerabilities.

It is also possible for someone to maliciously write a flawed JS file and put it on the CDN for others to use, which will affect all sites using it.

NPM has an example of this: the package getcookies has hidden backdoor programs, while express-cookies and HTTP-fetch -cookies rely on getcookies and MailParser relies on http-fetch-cookies.

Blog.npmjs.org/post/173526…

There are also many similar names of the project, such as the original package name is JS-cookie, malicious authors upload JS-cookies, Jscookie, Jscookies and other packages, cheating download. Be sure to double-check when using third-party dependencies.

Weak password

Weak passwords are not strictly defined and are generally considered weak passwords that can be easily guessed by others (who probably know you well) or cracked by a cracking tool. Weak passwords are those that contain only simple numbers and letters, such as “123” and “ABC”, because they are easy to crack.

ordinary

Common weak passwords are common passwords. For example, some people have compiled the Top 100 common weak passwords:

123456 a123456 123456a 5201314 111111 woaini1314 qq123456 123123 000000 1qaz2wsx 1q2w3e4r qwe123 7758521 123qwe a123123 123456aa woaini520 woaini 100200 1314520 woaini123 123321 q123456 123456789 123456789a 5211314 asd123 a123456789 z123456  asd123456 a5201314 aa123456 zhang123 aptx4869 123123a 1q2w3e4r5t 1qazxsw2 5201314a 1q2w3e aini1314 31415926 q1w2e3r4 123456qq woaini521 1234qwer a111111 520520 iloveyou abc123 110110 111111a 123456abc w123456 7758258 123qweasd 159753 qwer1234 a000000 qq123123 zxc123 123654 abc123456 123456q qq5201314 12345678 000000a 456852 as123456 1314521 112233 521521 qazwsx123 zxc123456 abcd1234 asdasd 666666 love1314 QAZ123 aaa123 q1w2e3 aaaaaa a123321 123000 11111111 12qwaszx 5845201314 s123456 nihao123 caonima123 zxcvbnm123 wang123 159357 1A2B3C4D asdasd123 584520 753951 147258 1123581321 110120 qq1314520Copy the code

For the website background, generally:

  • admin
  • manager
  • root
  • root123
  • tomcat
  • jboss
  • admin123
  • admin888
  • admin666
  • .

conditional

Conditional weak passwords are passwords related to user information, such as birthday + mobile phone number, initials + birthday, lover’s initials + birthday + common letters (520, 1314, etc.).

Hackers get their hands on the user’s information, use password psychology, social engineering, whatever, to guess the password. A lot of the movies we watch are about social engineering, about agents stealing employee cards and forging credentials, and the biggest vulnerability is actually people.

Bump type library

Many users use the same password on various websites. Hackers use user names, email addresses or mobile phone numbers from third-party user databases that have been leaked to match plaintext passwords with a certain probability of hitting.

Here you can check to see if it’s been screwed: haveibeenpwned.com/

A lot of well-known social work banks have been taken down, most of them on the dark web. Try this: publicdbhost.dmc.gripe /

Check: pipl.com

Registration website: www.zhaohuini.com/

Defense way

  • Each website set a different password, password more than 12 characters, do not and their personal information related.
  • Bank withdrawal password and birthday, ID number and so on.
  • Never store id photos in cloud storage, especially hand-held ID photos.

File upload

The browser saves the file to the server by uploading the page. These upload pages are usually limited (JPG/GIF/PNG, etc., or file size). The vulnerability page is roughly divided into two kinds, one is not limited to any format, random upload, this is now less. The other is to limit the Content-Type, which limits the file type but can be broken through.

Any file upload

For example, we put a sentence
write 1.php and upload it to the server. After that, try to access the uploaded file XXX /upload/1.php directly.

File type restriction

If only the front end does the extension restriction, you can use the interface tool to bypass it. If validation is applied to the back end, it must be done carefully. Hackers could also exploit known vulnerabilities in the server. For example, before Nginx, Apache, IIS have been exposed parsing vulnerabilities.

For example, suppose there is an image on the vulnerable site, and the URL is www.xxx.com/logo.jpg

When we access it normally, Nginx will treat it as non-script, read it directly and pass it to the client. But if we access it like this:

www.xxx.com/logo.jpg/a.php

He will execute logo.jpg as a PHP file. Or:

www.xxx.com/logo.jpg%00.php

It also causes the image to be executed by adding a
, the contents of the post argument a will be executed.

fishing

Fishing is also a very old form of attack. Many people will have such experience, QQ group inside someone hair what part-time job, what oneself want to go abroad house car sale, details in my QQ space, such as the connection. Open after the discovery of a QQ login box, in fact, a look at the domain name will know that is not QQ, but do very like QQ login, unknown users, really put the user name and password input, the result did not log in to QQ, user name and password but sent to the person in the past.

Many other phishing messages, often disguised as messages sent by banks, warn users of a security problem with their bank accounts and trick them into clicking on a link to fix it. Phishing messages link to a highly fake website that looks exactly like the official site, both in terms of ICONS and page design, to give the impression that the site is ok. The next step is to ask users to provide as much personal information as possible.

Phishing emails refers to hackers masquerading as colleagues, partners, friends, family and other users trust, through the way of sending E-mail, entice users to reply, click on the embedded email body malicious links or open E-mail attachments with implanted trojans or spyware, and steal the user sensitive data, personal information such as bank account and password, Or execute malicious code on the device to carry out further cyber attacks.

There are also spear phishing attacks, which differ from other types of phishing attacks in that they target specific people or employees of specific companies. Cybercriminals carefully collect information about their targets to make the bait more attractive. Well-crafted spear phishing emails can be hard to tell apart from legitimate ones. So spear phishing attacks are easier to bait.

Take the human resources department. Employees in the department receive a large number of resumes in a variety of formats, so receiving an email with an unsourced attachment is not unusual and would not raise suspicion. It’s easy to get fooled if you include links or attachments to your portfolio.

The only defense against phishing attacks is careful, don’t be cheap, don’t trust links and attachments, and remember common domain names.

unauthorized

An Escalation (or Privilege Escalation, or Privilege Escalation) is when an attacker is able to do something that he is not qualified to do. Simply put, it means “going beyond your authority and doing things you could not have done”. The cause of ultra vires vulnerability is that the developer overtrusts the data requested by the client while adding, deleting, modifying and checking the data and misses the judgment of authority. The overreach loophole is slightly less related to the front end, but because it is too common in the field of Internet finance, so let’s talk about it together.

China Financial Certification Center (CFCA) selected and analyzed the penetration test results of 113 electronic banking systems in 2017, which showed that among 306 security vulnerabilities of medium and high risk levels found, the vulnerabilities related to business security accounted for the largest proportion, with 210, while the common security vulnerabilities in traditional penetration tests, Such as cross-site scripting attack, SQL injection, arbitrary file upload, remote command execution and other WEB application security vulnerabilities, the existence of electronic banking system is relatively rare. Our security level is not much higher than that of electronic banking systems, so the above vulnerabilities should be looked out for.

Typically, when we use the functionality provided by a Web application, the process is as follows: Log in – > submit the request – > verify permissions – > query the database – > Return results. If there is a flaw in the “verify permissions” section, then it leads to overreach. A common case of over-authorization is that Web application developers have insufficient security awareness and believe that users can be authenticated through login. However, they do not perform further permission verification for user operations after login, which leads to over-authorization. Such as:

1. Implement access control by hiding URLS:

Some applications implement access control only through urls. For example, if you log in to the system as an administrator, you can view the link on the background management page. However, if you log in to the system as a common user, you cannot see the link. But by simply typing links, such as xx/admin/userlist, ordinary users can access the admin page.

2, Direct object reference:

For example, in an e-banking system, users can query account information using the following URL:

https://www.onlinebank.com/viewInfo.php?accountId=12345678

AccountId is the ID of the user account. After a user logs in to his/her account, the URL will appear on the user account page, and the user can click it to go to the account information page. Although no other user can see the link, if the access control of the e-banking system is not perfect, an attacker can construct the URL by enumerating accountId and then see the account information of others.

3. Multi-stage function:

Some of the application’s functions are executed in several phases, with multiple requests submitted to the server in turn during execution. This situation is very common, such as the transfer function, password retrieval function, need to verify the user’s identity, after the verification is successful, the user can perform subsequent actions. Multi-phase functionality is not a problem in itself, but if a developer believes that a user who has reached the later stages of the validation process must already have the relevant permissions, and does not validate the requests submitted by the user during the later stages of the validation process, then there is a high risk of overreaching vulnerability. It is entirely possible for an attacker to bypass the verification phase of the earlier stages and directly execute the subsequent actions.

For example, a website has made a very strict verification when retrieving the password. It needs to verify the information such as name, mobile phone number and ID number, and only after passing the verification can the password be changed. Verification is strict, but the site’s “password Recovery” feature is designed to be a two-step process (two requests are submitted) : the first step verifies the user’s identity, and the first request is submitted. The second step is the actual action of changing the password. The POST packet of changing the password has three request parameters, namely, the new password, the confirmation of the new password and the account value. Question is out in the second step, change the password in the implementation of the action, the server does not verify whether it is the first step is modified password account authenticated user accounts, so the attacker can easily with their own identity through the authentication, and then modify the second step is to submit a message, modify the password to any account!

Common functions with high incidence of overreach include: checking orders by order number, checking account information by user ID, modifying/retrieving passwords, etc.

4. Static files:

Some Web applications perform access control checks when a user accesses a dynamic page to determine whether the user has the necessary permissions to perform the actions. However, users will still submit requests for access to static resources, such as word, Excel, PDF documents from web sites. These documents are completely static resources whose content is returned directly by the Web server, which does not run on it. Therefore, static resources cannot perform any checks on their own to confirm user access rights. If these static resources are not effectively protected, then anyone who knows the URL naming rules can access these static resources beyond their authority. For example, Google hacking:

Many systems of Internet finance have loopholes of exceeding authority, I will not name them.

Creditease a platform of multiple unauthorized and arbitrary user login

Defense way

It is not easy to implement sound access control for an application, so overreach loopholes are not easy to prevent. For developers, it’s important to be security aware and vigilant. Such as:

  • Never trust input from the client (user).
  • The user must be authenticated before performing critical operations, and the user must be authenticated at each step of the multi-phase function.
  • For direct object references, encrypt the resource ids to prevent an attacker from enumerating the ids.
  • Authentication is not reliable on the front end, which validates user input and authenticates user permissions on the server side.

Note: After the implementation of the Cyber Security Law, all unauthorized penetration is illegal, so, most white hat activities are illegal, do not try.