Analysis of ASP. NET Web Application Security Solution

I. Security Risks of ASP. NET web application architecture

1. major threats to the Assembly: unverified access, reverse engineering, code injection, program information obtained through exceptions, unaudited access.

2. security risks between clients and Web applications: code injection (Cross-Site Scripting or buffer overflow attacks), network monitoring (password and sensitive application data detection), parameter cracking (form field, query string, Cookie, view status, HTTP header information), session status variable ID acquisition, Information Acquisition (usually exception ).

3. Security Risks between web application clients and Enterprise Services: non-audit access, cracking configuration data, network monitoring, unrestricted proxy, and data replication.

4. Security Risks between Web service clients and their services: Unaudited access, parameter cracking, configuration data acquisition, network monitoring, and message reply.

5. Security Risks between remoting clients and servers: Unaudited access, parameter cracking, serialization, and network monitoring.

6. security risks between the client and data: non-review access, SQL injection, detailed information on cracking data models and links, network monitoring, cracking configuration data, and cracking specific application data.

* ASP. Net Security Architecture considerations
1. Authenticate the user in the browser;

2. protect sensitive data in the browser and firewall channels. 2) block parameter cracking. 3) block session attacks and cookie reply attacks.

3. On the web application side 1) provide security configuration 2) handle exceptions 3) Audit users 4) Verify Input

4. Application Server 1) Authenticate and review uploaded identities 2) review and record activities and transactions

5. protect sensitive data between application servers and databases

6. Encrypt Or hash sensitive data in the database

 

Ii. Prevention and Control Measures for security risks of ASP. NET web applications

1. prevent cross-site scripting (cross-site scripting attack)

Attack method: attackers can input scripts or HTML content on the page to obtain sensitive data.
Threat index: 6

Attack result: the application rejects services or restarts, and obtains the error stack information (※) to speculate on the code for the next attack.

※Note: If customerrors is not disabled in the ASP. NET configuration file, the error line code or database connection string may be displayed in case of a System exception, which may cause configuration data leakage, causing a risk.

Preventive Measure: ASP. NET control verification or server-side input verification.

Client-side verification and server-side verification are used to verify user input. By comparing the consistency between the control input and Its HTML Decoding value, check whether the input string contains special HTML characters, this serves as a basis for converting special HTML characters to prevent the script from being triggered when the script is sent back.

 

2. Prevent SQL injection attacks (SQL injection attack)

Attack method: attacks that inject the input SQL text and return results by modifying the image input or URL parameters and taking advantage of the particularity of the SQL query conditions.

Threat index: 9

Attack results: Sensitive data can be queried and system data can be modified.

Preventive Measure: when data is updated and queried, convert the input parameters using the database parameter object or custom method to invalidate the injected SQL file.

3. Verify user input

Client-based verification and server-side verification (server-side verification is particularly important when client-side Javascript is disabled)

Client verification is mainly responsible for verifying the type, length, and Association of user input (this function is provided by the system extension control );

Server-side verification is divided into two parts:

1) input verification

For input verification, You need to verify the HTML special characters of the user's input text, and throw a system error if there are special characters. The length of data should be controlled as far as possible through the allowed input length of the control on the screen;

2) data verification

Verify the data type and length. This verification behavior is performed on the object.

4. Use the hash algorithm to save the password

ASP. NET membership is used to manage users. The user password is encrypted using the hash algorithm and salt, which is highly secure;

For other passwords to be saved, the system infrastructure provides the hash Encryption Algorithm for non-reverse encryption, which is used as verification creden。, or is used first without being saved in data storage.

5. Data Security

1) Encrypt Sensitive data: the infrastructure should provide hash encryption algorithms to support data encryption.

2) XML data security: prevents XML data attacks.

Attack methods: XPath injection and XXE (XML Entity extension) injection attacks.

Threat index: 8

Attack result: Get XML file information.

Preventive Measure: Do not store sensitive information in XML. All sensitive information in configuration files must be encrypted and saved. Data to be written into XML must pass verification first.

3) viewstate Data Security: prevents sensitive data from being obtained from viewstate.

Attack method: obtain sensitive information by decoding viewstate.

Threat index: 6

Attack result: obtain sensitive information in viewstate.

Preventive Measure: Disable or avoid viewstate, and use simple controls to save sensitive information in encryption mode.

Association problems: handle sensitive data when using JSON strings.

6. Store security information to the Registry and configuration file

Controls the access permissions of remote users to the configuration file to protect sensitive data in the configuration file.

7. modify the configuration file before publishing

To prevent misstack information speculation and attack by other means of information discovery, ASP. NET web applications should correct the configuration file before release.

Speculative attack of error stack information

Attack method: System exception occurs. The code on the error page is used to speculate on the next attack.

Threat index: 6

Attack result: speculative system version and code logic.

Preventive Measure: capture system exceptions and use the unified page for handling. This does not indicate the error stack information, set the custom error node to <mermerrors mode = "off"/> to prevent the error message from being displayed to the remote user; disable the debug switch <compilation defaultlanguage = "VB" DEBUG = "false"/> to prevent source code leakage or code injection by debugging information.

At the same time, we should disable trace optimization performance and prevent attackers from using trace to speculate on the Code Execution Process and details: <trace enabled = "false" requestlimit = "10" pageoutput = "false" tracemode = "sortbytime"/>

Web services should prevent remote users from using the WSDL description for speculative attacks.

Attack method: access the Web Service WSDL file to obtain information about the web service.

Threat index: 4

Attack results: Obtain the Web service method description, speculate web service parameters, and perform the next attack.

Preventive Measure: In the configuration file, specify the content that does not represent the web method description. modify the configuration file as follows:

<WebServices>

<Protocols>

<Remove name = "documentation"/>

</Protocols>

</WebServices>

 

8. Use a session but not a cookieless session

Cause: the session of cookieless will expose the sessionid in the URL, making it easy for others to attack.

9. Preventive Engineering

Attack method: Obtain the Assembly and use tools for reverse engineering.

Threat index: 9

Attack results: Understand Program Logic and steal development results.

Preventive Measure: perform strong encryption and obfuscation engineering at release.

Refer:

ASP. NET security: 8 ways to avoid attack

Http://www.devx.com/security/Article/20898/1954

Hacking exposed Web 2.0: Web 2.0 security secrets and solutions, rich cannings, Himanshu Dwivedi, Zane lackey, 2008.