How can we deal with SQL injection to cope with XPath injection?

Q: What is the difference between XPath injection and SQL injection? Can SQL injection attacks mitigate XPath injection attacks? Experts replied: XPath (XML Path Language) 1.0 is an expression language. Many applications use this language to operate based on the content of XML files. An XML file can be used as a database. XPath queries are used to access data in this file. Benefits of using an XML database instead of a traditional database include portability, compatibility, reusability, and structured performance. Although the syntax expressed by XPath is similar to that of SQL queries in many aspects, XPath injection is more dangerous than SQL injection. When a Web application builds an XPath query without verifying the data provided by the user, XPath injection can take advantage of these applications. An attacker can inject data into a query to change its semantics. By embedding a series of Boolean queries (a well-crafted expression that can generate "true" or "false" values), attackers can repeatedly view all nodes of the file. Using this technology, even an attacker who does not know how to query XPath can extract a complete XML database file. Most databases provide some form of access and permission control to restrict users from accessing certain tables, fields, or queries. This restriction is generally used to restrict attackers from accessing the database account of the application. XPath does not restrict access to database files. Therefore, attackers can query all XML objects in the database. In addition, because XPath is a standard language, attackers can create an automatic attack tool suitable for any XPath-based application. Because of SAL's many variables, SAL injection attacks must be tailored to the SQL statements of specific versions of the target being attacked. The measures used to defend against SAL injection attacks actually help defend against XPath injection attacks. Below are some defense steps that can be taken for evaluation. First, your application must verify and clean all content entered by the user. Second, before using this data for your scripts, data access routines, and XPath queries, assume that all the data comes from untrusted sources. It is worth noting that it is useless to verify only on the server side rather than on the client side, because client verification is easily bypassed. Unfortunately, there is no original XPath to set the query parameters. Therefore, XPath queries have to use string construction technology. This makes it more important to verify all input content provided by the user. Test whether your application is vulnerable to XPath injection attacks. Just add a quotation mark to the data sent to your server to see if an error occurs. If an error occurs, it indicates that an XPath injection attack may occur. XPath 2.0 technical specifications are currently in the final stage of the W3C approval process. This technical specification provides a set of functions and capabilities that are greatly extended, but unfortunately it does not add security features.