WEB application vulnerability Prevention Policy

In fact, WEB applications are very fragile. This type of application is flexible and has a high degree of freedom of user input. Therefore, it is easy to launch malicious attacks on WEB applications.
 
This article provides some solutions for 16 common WEB attacks.
 
1. SQL Injection)
 
Fixed SQL statements are generally not processed at the application layer. We recommend that you add a packaging class to control these fixed SQL operations.
 
For dynamically generated SQL statements, user input must be processed. Generally, ['] is converted to ["].
 
For example:
 
Abc "def" ghi 'jkl 'mno → abc "def" ghi'' jkl ''mno
 
2. Cross-Site Scripting (XSS)
 
If you enter a URL parameter on the page, special text must be filtered.
 
2-1 if the user input and URL parameters contain the following sensitive text, delete it:
 
Script Object Embed Applet
 
2-2 if the user input and URL parameters contain the following sensitive text, convert it:
 
& → & Amp;
<→ & Lt;
> → & Gt;
"→ & Quot;
'→ & #39;
 
3. OS Command Injection)
 
Do not execute system commands whenever possible. If not, process the following user input or parameters:
 
|! & 'The characters that are always used for Command Execution
"'Character string Differentiation
/-Command parameters refer to the regular characters used
"./¥ Directory refers to the regular characters used
<> File operations are the characters used
$ Environment variable refers to the regular characters used
({[]}) Delimiter between commands
 
4. Line Feed Code Injection)
 
In the user's input information, check whether the line feed input "0x0d" and "0x0a" is not included.
 
5. LDAP Injection)
 
When using LDAP, check whether the user input does not contain the following LDAP reserved words:
 
() * ¥ NULL
 
6. Xpath Injection)
 
When using XPath, check whether the user input does not contain the following Xpath reserved words:
 
<> "'&
 
7. SSI Injection)
 
Check whether user input does not contain SSI-related dangerous keywords.
 
8. Directory Traversal (Directory Traversal)
 
Check whether the user input does not contain special texts [/] and [\] used to access the file system 【\].
 
9. Forced Browsing)
 
The prevention of such attacks is complicated. The general strategy is:
 
Verify whether a request is sent from a valid page. Generally, it checks the Referer of the request.
User authorization control, authentication and approval
For static resources, WEB programs cannot prevent such forced browsing attacks. They can only prevent the attacks by setting middleware (such as WEB servers:
 
Setting of open website directories (for example, disabling the display of file lists under the site directory)
Specify the contents in the URL, such as index.html, and so on)
Exercise caution when setting the storage location of downloaded files.
10. Cross Site Request (Cross Site Request Forgery)
 
Define the page operation process and filter requests that do not comply with the operation process.
 
11. Incorrect file and directory Allocation (Invalid Allocation of Files and Directories)
 
Do not store non-public configuration files, backup files, data files, etc. in the public directory of the site (WebRoot or www/htdocs)
Library files used by WEB applications should not be stored in the public directory of the site.
Resources suitable for storing in public directories are as follows:
 
/Var/www/htdocs/
Img/
Css/
Data/
Index.html
 
12. Incorrect Error Handling (Invalid Error Handling)
 
Make sure to handle the error. The error message must be displayed as understandable content, and do not display the error message of the middleware (WEB Server.
 
13. Unnecessary Information (Unnecessary Information)
 
For example, when a user logs on to the system, the error message [incorrect user password] is displayed, indicating that there is a user named userid in the system. This provides intelligence for malicious attackers.
 
Therefore, when processing the message displayed by the system, no extra user details can be exposed until the point arrives.
 

 
14. Backdoor & Debug Option)
 
Avoid special password input and authentication policies
If the debugging option is specified, both the debugging option and program parameters can be changed and viewed.
Page dedicated for testing
Program backdoors can be prevented through enhanced code review.
 
For debugging options, uniform development standards should be adopted, and unified debugging switches should be used.
 
15. Client Side Comment)
 
For WEB applications, the client can directly view the Page code through a browser. The comments sent to the browser code can be comments by developers. For malicious attackers, these comments expose many details of the WEB application.
 
For example, the annotations mentioned below should attract attention:
 
Comment on Request Parameters
Comment on the internal logic of Javascript
External Javascript internal logic and URL requests
The corresponding policy is as follows:
 
A unified code specification must be provided in advance for code comments.
Try to use the server-side annotation tag, such as <% -- %> in JSP. Such annotation content will not be sent to the client.
16. Buffer Overflow (Buffer Over Flow)
 
If the user input contains an input that exceeds the server buffer size, it may result in insufficient server storage or even server downtime.
 
The countermeasures are as follows:
 
Check the size of user input
File Upload is to check and limit the size of the uploaded file.