Some solutions to bypass MSSQL injection prevention

At work or other times, I often encounter some websites with anti-injection code, which is really a headache, however, on the other hand, I finally had a new topic that could be considered in depth. At the same time, I also saw many methods provided by my predecessors to bypass anti-injection, which really benefited me a lot. Let's focus on the following points:

1. Encoding
2. Statement Transformation
3. Miscellaneous

I would like to briefly describe these points!

Encoding->
There are countless issues with coding in google, but there are also a lot of coding issues. Here are some of the common ones:
1) The Urlencode encoding is very common, for example, % 31% 3d % 31. However, the effect in bypassing anti-injection is not very good, unless the server only judges the url address in the browser.
2) ASCII is usually a little more frequently used. char (xxx) should be familiar to everyone. Add the corresponding ascii code in it and connect multiple ASCII codes with +.
3) Hex is a very classic bypass technology. However, because mssql does not provide functions such as unhex (), the preceding statements must support clauses, define it and assign values to it.

Statement conversion->
To implement a function, we can use different statements. One of them may be statements suitable for the current environment. Let's look at the following SQL statements, it is also frequently used in the injection process.
Select password from users
Convert (int, select password from users)
This may allow us to get the password. Don't worry. This is just an example of changing sentences. Now let's take a look at what if some query keywords are filtered out in anti-injection mode?
Select password from users // unable to execute because the password is filtered
Declare @ pw varchar (1000) set @ pw = 0 × 70617373776F7264; select @ pw form users; // this way, the special characters can be bypassed through hex processing, it mainly deals with special situations, such as IDS and other security devices. It is also very good to bypass anti-injection in other ways.

Others->
In addition, we can use some special methods to bypass, such as in and between. For example, if select is filtered, see the following.
Select password from users // filter select and cannot be executed
S % e % l % e % c % t password from users // connect through %
"Sel" + "ect" password from users // connect through +
Se/**/lect password from users // connect through /**/
Second, in some anti-injection scenarios, because the script does not filter cookie submissions, we can inject them through cookies. In fact, there are many methods, the problem of thinking about the last time is finally solved through statement transformation. The flexible running of SQL statements is really violent in some cases. You are welcome to discuss the above points.