I don't think mysql anti-injection is necessary?

I don't think mysql anti-injection is necessary? Recently, I have been studying SQL Injection Prevention to escape some special characters entered by users. I don't think this is necessary.

When a user logs in, I only allow numbers, letters, and underscores. if a special character appears, I am prompted that it is not correct.

Are you right?

Reply to discussion (solution)

Are you restricted on the client or on the server?

Are you restricted on the client or on the server?

On the server side, if a php regular expression is found to be not a character that is not allowed by me, the system will directly prompt that there are special characters, and there will be no dql or chance to inject these special characters,

Of course, this is my idea. I don't know if there are any drawbacks.

What else do we do to prevent injection?

Of course, this is my idea. I don't know if there are any drawbacks.

Is the landlord optimistic about it recently?

Many advanced systems can be cracked if they want. We just need to prevent Cainiao from breaking through. Others

People who want to destroy your program will certainly not use your page as normal people do. they can bypass your input box, such as directly operating in the address bar, when there is a gap, it will allow others to inject...

Only numbers, letters, and underscores are allowed.

If so, there is no database injection.

SQL injection is not only an input box, but also an input parameter in the address bar.

Many advanced systems can be cracked if they want. We just need to prevent Cainiao from breaking through. Others

Basically agree.

Are you restricted on the client or on the server?

On the server side, if a php regular expression is found to be not a character that is not allowed by me, the system will directly prompt that there are special characters, and there will be no dql or chance to inject these special characters,

Since it is server-side verification, as long as the verification is in place, it should be okay ~~~

Newbie passing

Anti-injection is already being performed when you judge the parameters.

Attention: many open-source systems in China can be injected at will, but they won't work like drupal. they are completely database abstraction layers and cannot be injected.

------------------------------------------------------ AutoCSDN signature file ------------------------------------------------------

Code farm-farm where code farming and grazing ideas are planted by code farmers!

I feel that verification during login registration can only prevent the emergence of a universal password. something like commenting out the judgment statement behind SLQ.

Use PDO, strictly follow the format, so you don't have to worry about injection.

The anti-SQL injection method that the landlord understands is too specific. special character conversion and strong verification of parameters are all measures to prevent SQL injection. The cooperation between the two is good.

User-submitted requests to filter out invalid characters.

16 # absolutely correct

Anti-injection or something! It's all about anti-bot!

Are you directly making judgments on the client? If you make a judgment on the client side, do not first make a judgment on the client side of the security is not safe, the client side to make a judgment using JS, others can set the JS script on the client side does not load, do not execute JS! Your judgment is just like a false one. if you use the server side, you still need to perform SQL injection.

Sometimes it is not too one-sided. the existence of SQL injection prevention has the meaning of its existence. a single judgment on the client will only cause your database to crash, the client is the only path and the most dangerous SQL exit for the user. it is usually used to filter the client and prevent an SQL injection.