Preface
Front-end debugging is an important part of security testing. It can help us master the operating principles of web pages, including the logic of js scripts, encryption and decryption methods, network request parameters, etc. Using this information, we can more accurately discover website vulnerabilities and develop effective attack strategies. For security, front-end knowledge can not only improve testing efficiency, but also broaden testing ideas.
The following case is a problem I encountered when testing a backend management system. Originally, the interface and fields were discovered through js on the login page, but when the request was made, it was found that it was not an unauthorized vulnerability, but the fields only had new passwords and usernames. Then there is a high probability that there is a loophole in this.
text
This is an authorization test, and the customer has to provide an account and password. Change the password in the background:
JavaScript analysis
When I entered the correct password, it disappeared again, indicating that there was a verification. Either back-end verification or front-end verification. From the js content before login, you can roughly guess that this is the front-end verification.
I used burp to capture the packet and found that no request passed:
Explain the high probability of front-end verification (it may not be caught, but the probability is very small). The next step is to analyze the front-end js. Here I mainly analyze the judgment logic of the "Inconsistent with the initial password" prompt message in the text box:
There are two main methods for my analysis here:
①Event listener:
Use the event listener to find the corresponding js event, view the js through the forward direction, and follow the corresponding function to conduct code audit layer by layer:
But by looking forward, we found that it was called through multiple layers. And all codes are highly compressed and obfuscated.
At this time, you can also find it through other buttons. There is a high probability that the js that handles the logic is all together. Of course it's just possible.
To help network security students learn, get a full set of materials for free:
① Network security learning and growth path mind map
② 60+ network security classic toolkits
③ 100+ SRC analysis reports
④ 150+ network security attack and defense practical technology e-books
⑤ The most authoritative CISSP Certification exam guide + question bank
⑥ Over 1800 pages of CTF practical skills manual
⑦ Latest collection of interview questions from major network security companies (including answers)
⑧ APP client security detection guide (Android + IOS)
Find the submit button.
Clicking will result in an error. Check out the logic of this submission:
Find submit and check the calling js code:
Unfortunately, it is still this confusing js that is incomprehensible. I can't enter the function even if I hold down ctrl, I don't know why. GG.
② Directly search for the corresponding keywords and browse in js
This method should be the most commonly used method by everyone. Directly search for keywords, such as encryption and decryption, directly search for encrypt, which is generally effective.
For example, here, you can directly search for the error message: inconsistent with the initial password:
Every time I look for it, it's always 0. At this time, you should consider whether it is possible to save it in css, or use urlencode or Unicode encoding.
(PS: Since there is no request for the backend, we will not make assumptions about the response from the backend. Otherwise, if the normal string cannot be found on the front end, it may be returned by the backend.)
First convert these characters to Unicode encoding to view. When querying as characters, it is recommended not to query all characters, because sometimes it may separate the corresponding strings or splice them. Use several keywords that can be directly searched, such as those that are not easy to repeat. For example, "consistent" here.
For search, you can proxy both js and html pages out of burp, and then use burp's own search, which may be more convenient. This is how I use this method to query:
Luckily, I found it!
+-----------------------------------------------------------------------+| function At(n, o) { || || 1 & n && (t.TgZ(0, "mat-hint"), || || t._uU(1, || "\u4e0e\u521d\u59cb\u5bc6\u7801\u4e0d\u4e00\u81f4"), || || t.qZA()) || || } || || function bt(n, o) { || || 1 & n && (t.TgZ(0, "mat-hint"), || || t._uU(1, || "\u4e0e\u8bbe\u7f6e\u7684\u5bc6\u7801\u4e0d\u4e00\u81f4"), || || t.qZA()) || || } |+=======================================================================++-----------------------------------------------------------------------+
You can see that js is highly confused.
It is difficult to audit. Here we only need to check who called this function and find the logic online.
There are several ways to find it. Here I borrow new bing’s answer:
Hello, this is Bing.
Based on my search results, there are several ways to achieve this functionality in Chrome. I'll introduce you to some of these methods:
1. Use the search function of Chrome Developer Tools¹. You can press `ctrl + shift +F` (Windows) or `cmd + optn +F` (macOS) to open a search window across all scripts. You can then tick the "Regular Expressions" checkbox and search for the function's name and how it is defined. For example, if you want to find a function named `foo`, you can search for `foo\s*=\s*function` (meaning there are any number of spaces between `foo=function`) or `function\s* foo\s*\(` (meaning `functionfoo(` with any number of spaces between them). The search results will show the script and location where the function is defined, and you can click on them to jump to the corresponding line of code.
2. Use the call stack function of Chrome developer tools. If you want to find out where a function is called from, you can add a breakpoint inside the function body and run the code. When the code execution reaches the breakpoint, the developer tools will pause and display the current call stack. You can view the order and position in which functions are called, as well as the parameters and local variables of each function in the call stack panel.
3. Use JavaScript code to get the caller of the function³. If you want to get where a function was called from in your code, you can use the arguments.callee.caller property to access the caller of the current function. This property returns a function object, and you can use its `name` property to get the name of the function, or its `toString()` method to get the source code of the function. If the current function is called from the global scope, then this property will return `null`, you can use conditional judgment to handle this situation.
I adopted the second point here, and you can see the stack calls here.
Successfully found the password judgment point:
Next, you can change whatever you want to change.
JavaScript local modification debugging
After finding the corresponding function, the next step is to modify the content in js. If you want to modify js and debug it on the front end, you need to add a folder in the replacement, and then save it in the js editing interface. If the save is successful, there will be a small purple dot:
Add a console.log in js to test and debug. After triggering this function, it prints successfully:
If you want to bypass it through the front end later, you can also debug the submit button.
end
Some people may say, why go through so much trouble? This article only explains some debugging ideas, and has nothing to do with this vulnerability. It is just used as a case explanation. I am not a front-end person, I mainly do sharing and use. I learned many aspects of knowledge myself only after having been exposed to them. Maybe for some big guys, these are very basic, so don’t criticize them. Dig a hole for yourself. If the response to this article is good, I will share with you how to debug and test some web sites that encounter js front-end encryption and decryption.