Shulou(Shulou.com)05/31 Report--

Editor to share with you how to make sure that SQL injection is dead, I believe most people do not know much about it, so share this article for your reference, I hope you can learn a lot after reading this article, let's go to know it!

For a long time, I thought that the most common security problem in back-end development was SQL injection. Through the magical SQL writing of where 1, it is easy to attack a problematic system, so that artifacts such as sqlmap eventually exist.

Later, fastjson refreshed my understanding, and this framework is also a promotion of the concept of Internet security. Even the boss who does not understand the technology knows that fastjson is so fast that the security concept of the programmer has been improved.

Why do you have a passion for sql injection? Because developers deal with SQL in too many places. Even some students who specialize in developing reports write more lines of SQL than the number of lines of code!

The problem is. A long time ago, as early as 10 years ago, someone was saying that SQL injection was dead, but to this day, there are still a large number of SQL injection tutorials and SQL injection cases.

SQL injection is the king of vulnerabilities, which is not a boast.

Of course, in this regard, PHP has made the greatest contribution, and Java is willing to be outdone.

The reason for the popularity of SQL injection is that developers are too confident in themselves, or the tools they use are too primitive to filter through the framework layer. If you use MyBatis or JPA in the Java world, the likelihood of SQL injection becomes very low. Now PHP also has a framework similar to thinkphp, which means that there are fewer and fewer SQL injection vulnerabilities.

But it doesn't mean no, it's just that the threshold has been raised. Let's take MyBatis as an example to see if SQL injection can still occur.

SQL injection still exists in MyBatis

For students who use Mybatis, the first concept of contact is the difference between # and $. These two symbols are very much like magic symbols in Shell, but fortunately there are only two cases.

# represents the use of sql precompilation, which is safe and reliable

$means the splicing method is used and there is a risk of SQL injection.

For example, the following xml configuration is an absolutely safe way to write it. Because the entire # {id} will be replaced with?

SELECT * FROM order WHERE id = # {id}

Unfortunately, there are some scenarios that cannot be precompiled (or you just don't know or are lazy). Like some code refactoring, when the fields such as table name / column name / sort are passed in dynamically, it is inevitable that SQL splicing is needed, and SQL injection is still in progress.

But similar statements such as LIKE and IN are more likely to cause problems.

The following are two sentences of Like fuzzy query writing, the actual test will find that the use of # does not work, will report an error, need to use sql spliced $. The problem arises from this.

SELECT * FROM order WHERE name like'% # {name}%'/ reporting grammar error SELECT * FROM order WHERE name like'% ${name}%'/ / can be run

And the correct way of writing, should use function concatenation. But the time limit is so overwhelming that before you know it, most people choose a simple way to write it. After all, function comes first, and it is also the most important way to reflect the workload.

SELECT * FROM order WHERE name like concat ('%', # {name},'%') / / correct writing

The same problem exists in the IN statement.

In (# {tag}) / / error in (${tag}) / / can be run

Since it can be run in a few characters, of course no one chooses the complicated way to write it below.

Tag in# {tag}

And order by, do not take it lightly, if you are not careful, it will be doomed forever.

SELECT * FROM order order by createDate # {sortType} / / error SELECT * FROM order order by createDate ${sortType} / / normal

In this case, you need to whitelist sortType. There is only one ASC and DESC, you send me a long string, what's going on?

Summary

SQL injection will still exist in 2021, but the threshold has been raised. Now the reduction in SQL injection is due to the work of the framework, which has nothing to do with the level of programmers. The situation of sql splicing will never go away, because it is the quickest and easiest way to stop. Numerous outsourced projects and systems that have been lying still for more than ten years can be found everywhere. It is a dream to hope that all SQL injection will be eliminated in the framework layer.

Because its opponent is the laziness of human nature. No one can beat it.

The above is all the contents of the article "how to make sure SQL injection is dead". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

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.