SQL Injection Attack solution based on ACCESS Database

Author: yf4n from: XI ke Information Technology Silic Group Hacker Army
Note:

All the situations discussed in this article are based on the ACCESS database, because the injection methods for ACCESS databases are generally fixed and easy to defend against, while other types of databases have more and more attack techniques, which are more difficult to defend against, and because of my personal technical level issues, the solutions for other types of databases will not be discussed for the moment. Therefore, if your website is not an ACCESS database, this article will not solve your problem.
There are only a few methods to solve the SQL injection attacks on the ACCESS database:
1. Start with your own code, modify the source code, and filter all variables.
2. Start with your own code, modify the source code, and write the Administrator information directly to the login authentication file, not in the database.
3. Start with the database structure and place the Administrator information in a raw and difficult-to-guess table.
4. Start with external code and mount anti-injection code
My personal opinions on these solutions are as follows:
Solution 1 is undoubtedly the most labor-intensive, time-consuming, and effort-consuming. We cannot guarantee that all the variables will be completely filtered out upon one modification. After all, the Code is not good-looking. Furthermore, because the injection method is too flexible, we may not consider too many situations, resulting in incomplete filtering. If so, attackers can also make breakthroughs, however, this method is the most reliable and bottom-layer solution. After all, it is the code we write ourselves and we can rest assured.
Solution 2 is a very secure method. I personally recommend this solution because it is not afraid of injection attacks because our administrator's username and password are not stored in the database, even if there are injection points on my website and attackers have successfully exploited them, attackers cannot obtain our administrator usernames and passwords, and naturally cannot control our background, therefore, this method is recommended.
Solution 3: This solution is a better method when we do not want to modify the website structure, because we generally use CMS or other sets of systems, if we modify the source code on our own, there may be problems, so if you do not want to modify the source code, this method is also feasible, because we know that the injection attack on the ACCESS database, they all go through the "Guess table", "Guess field", and then blow up the content. Therefore, if an attacker finds that our website has an injection point, but our table name is very complicated, it is not a regular table name, so attackers cannot exploit this injection point at this time. Using this method, we can also build a dual line of defense, it is to make the table name settings more complex and also make the column name settings more complex, so that it is OK.
Solution 4: I personally do not recommend this method. It is completely a temporary solution, and according to the well-known general anti-injection program on the Internet, they are not completely effective. They all filter post and get data, but they do not filter cookie set data. Attackers use cookie injection to bypass these so-called universal anti-injection methods, therefore, the fundamental security of the website cannot be guaranteed. In addition, how do we know whether the code written by others is easy to use or use? Do not clearly stick to the general anti-injection service, but discover that it cannot be prevented at all. This is a tragedy.
I can say so much about the SQL Injection Attack solution based on the ACCESS database. Thanks for the guidance of niailuo. Thank you.