The basic requirements

Use basic Web security defense policies (XSS, CSRF, unified Login, and so on)

Do not expose debugging information (Do not enable the Debug mode in test and formal environments. You are advised to standardize error logs and view logs to locate faults)

Access restriction (IP or QQ whitelist) (use the permission management function provided by Blue Whale Developer Center)

Unauthorized Operation prevention and self-check (associated authentication of users, services, and operation rights) (refer to unauthorized cases)

Permission recycling (application of unified recycling notification module, regular notification of service test leader to sort out and confirm the permission of external personnel, application development framework integration)

Internal applications that provide apis for external applications and perform authentication must be reported

Webshell must report this

Flash XSS vulnerability (for example: Zeroclipboard plug-in, please upgrade the plug-in to the latest version)

Common XSS vulnerabilities and solutions

Scenario 1 Storage XSS: [Definition]

The data input by the user is "stored" on the server side. When the user browses the page, the generated page is read from the server side and presented to the userCopy the code

[example]

< H1 > some_user_INPUT </ H1 > or <imput type= "text" name= "address1" value=${" address "}>Copy the code

“Address”

In order for the browser to properly display these characters, rather than execute them, we need to use HTML entity characters. Do an escape before the data is stored, such as escaping <script> to &lt; Script&gl, middleware implementation, to ensure that the middleware is in use for the output to the content of the front end, we also want to filter, prevent because after the input filter is around, you can use the mako h parameter of the template (${name} | h) for not mako template rendering display content, Need to do HTML special characters escape, pay special attention to the front end of the title, name, class and other attributes of the assignment also need to do conversionCopy the code

“Test”

To detect all user input parts, type <script>alert(' XSS '); </script> Check to see if the presentation section is popover.Copy the code

Scenario 2 Reflective XSS: example

For user input, we sometimes do not simply display it in the tag as in scenario 1. For example, $("#my_input").val("some_message") is used for auto-filling the form; <img SRC ="some_message"> <img SRC ="some_message"> <img SRC ="some_message"> <img SRC ="some_message"> <img SRC =x onerror=alert(1); $("#my_input"). Val (""><img SRC =x onerror=alert(1); > "); The original assignment statement is damaged. If persistent data is stored, services will be affected. <img SRC =" ><img SRC =x onerror=alert(1); >"Copy the code

“Address”

Similar to scenario 1, filter and escape the input content with special charactersCopy the code

[Test] To test all user input parts, input

"><img src=x onerror=alert(1); >Copy the code

Check whether the display section is popover and whether business functions are affected.

Scenario 3: File upload and Import: For imported or uploaded files, the escape of special characters is ignored. As a result, XSS attacks occur when file contents are displayed in the front end

For example, Excel imports user data and generates a table

After the information is imported, it is passed to the front table, resulting in the XSS within the tag in scenario 1. For example, the file is uploaded and displayed

In non-Windows operating systems (such as Lunix and OSX), file names can be named in any format and can contain JS code, causing XSS attacks when displayed in the front end after uploading

“Address”

Verify Excel and file import data and escape special characters, including but not limited to single quotation marks, double quotation marks, back quotation marks, Angle brackets, &, and so on. The background verifies the size, content, and type of the uploaded file. Only when the file name of the file type that met the requirements last time is displayed in the front end, special HTML characters are escapedCopy the code

“Test”

Try using <script>alert(' XSS ') in the imported Excel; </script> and "><img SRC =x onerror=alert(1); >Copy the code

To check for pop-ups and business function integrity. Name the file name of the upload file as

"><img src=x onerror=alert(1); >.zipCopy the code

Or to check whether pop-ups and business function integrity. XSS is used to test payload

<img/src='x'onerror=alert(document.cookie)>
Copy the code

Scenario 4 Error message: [Example] The path to upload the file is written

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

During the execution, an error occurs in the path, and the information filled in by the user is displayed in the front – end message. As a result, XSS attacks occur

“Address”

In the same scenario as scenario 1, special HTML characters must be escaped when user input is displayedCopy the code

[Tests] Enter the place where the file is uploaded or distributed

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

Check whether the system works properly and whether the results meet expectations

Scenario 5 Close the vm in advance based on user input

Using the principle of browser parsing HTML, the <script> tag is closed ahead of time through user input, resulting in the subsequent JS code directly exposed to the front pageCopy the code

[Example] The following simple three pieces of code can cause the script to close early, and the rendering of user_variable formally uses the common scene of Mako rendering:

<script>
    var user_variable = "</script>";
</script>
 
Copy the code

When mako is rendering, the user input information is output to HTML in Python as base64, so that all special symbols entered by the user are converted to letters and do not cause script tags to close prematurely during HTML parsing. Finally, use the BASE64 decoding of JS to convert the user variable once before applying it

XSS is used to test payload

(1) <script> alert('xss')</script> (2) http://localhost/x.html#<script> alert('xss')</script> (3) <script src=http://www.qq.com > < / script > (4) "> < script > alert (1) < / script > (5)" > < img SRC = x onerror = alert (XSS) > (6) "> < iframe src=javascript:alert(1)></iframe> (7) </script>Copy the code

Common ultra vires loopholes and solutions

Common overreach classification: 1. Parallel overreach

Scenario 1: Common user A can access user B's data Scenario 2: A user can modify the request link or parameters to access other data that is not allowed to accessCopy the code

2. Overstepping authority

Common users can perform administrator operationsCopy the code

Scenario 1: Overreach on explicit URL changes in GET requests

As for the URL format of the figure, without strict judgment, especially when API mode is used in the background, users can access any page by changing the number after /detail/ at will, bypassing permission judgment.

“Address”

Strictly check the user identity and operation ids. You are advised to add service fields to the URL to determine whether the user has the operation permissionCopy the code

“Test”

Change the ID in the URL to an out-of-privileges page ID to check for unauthorized access and return pages as expectedCopy the code

Scenario 2: Unauthorized modification of preset parameters in a POST request

Fixed POST parameters, such as input in the hidden property, or data in Ajax that is determined when the page returns, can be modifiedCopy the code

As shown in the figure, the page is rendered with a Report_id, which the user takes to download the corresponding file when they click the button. If there is no permission control in the download logic, the ID can be changed to download arbitrary files, resulting in overreach.

“Address”

Same as scenario 1, improve the permission control of view functions.Copy the code

“Test”

Use Fiddler to fetch request packages and modify parameters in post requestsCopy the code

Scenario 3: Non-administrator user access management interface {three} Usually an app has an administrator interface to facilitate configuration. The general approach is to control the front end. The urls of the management interface are not exposed to non-administrator users. However, non-administrators can obtain all urls and access them through various means.

“Address”

Background management operations need to be verified on the background to prevent unauthorized users from accessing themCopy the code

“Test”

Use a normal user account to try to access the administrator interface or the CGI for administrative operationsCopy the code

Overreach testing methods are commonly used

Test point 1

Obtain the data packet of user A’s operation request, request with user B’s identity, and see the returned data (after page operation, use Fiddler to capture the request packet, and use user B’s identity to request)

Test point 2

1) After modifying the service ID and other data in the request link, initiate a request and determine whether the request is unauthorized. 2) After modifying the service ID and user name and other data in the request parameters, initiate a request and determine whether the request is unauthorized (using Fiddler to capture packets) **Copy the code

Common CSRF vulnerabilities and solutions

Scenario 1 JSON_Hijacking

Json hijacking is a type of vulnerability of CSRF, where hacker-controlled third-party sites use CSRF to force users' browsers to request Json data from CGI, allowing hackers to access sensitive informationCopy the code

[Vulnerability detection]

Use a tool to get JSON data.Copy the code

[Bug fix]

Add token (random string) to request referer validation (restricted to valid sites and not null)Copy the code

[Precautions]

Online JSON defenses against malicious calls from outfields only restrict referers, but allow empty referers to access them: local HTML, for example, and some pseudo-protocol remote calls without referers. And that perpetuates the problem. So the empty referer is not safe eitherCopy the code

“Address”

Django's CSRF middleware protects against CSRF attacks. Post requests are usually used for important add, delete, or change operations. However, if it is a GET request to obtain sensitive information, the above problems may exist. It is suggested to obtain CGI with sensitive information by GET, or change it to POST or add referer verificationCopy the code