使用MySQL重新进行SQL注入攻击,基线要求是什么? [英] re SQL Injection Attack using MySQL, what are baseline requirements?

查看:61
本文介绍了使用MySQL重新进行SQL注入攻击,基线要求是什么?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在当前使用MySQL的项目中.查看mysqli函数,发现它们很难使用.我认为,使用该库的任何程序员都应该获得荣誉勋章.

In current project using MySQL. Looking into the mysqli functions, found them to be very difficult to use. In my opinion, any programmer using the library should have a Medal of Honor.

三个问题:

  • mysqli无法处理NULL或CURRENT_DATE之类的功能
  • 对于带有随机WHERE子句的查询,无法使用参数化的SQL语句(那么如何防止SQL注入攻击?)
  • 在我看来,在复杂情况下使用sqli太繁琐了(请参阅链接)
  • mysqli does not handle NULL or functions such as CURRENT_DATE
  • it is impossible to use paramterized SQL statements for queries with random WHERE clauses (so how do you prevent SQL Injection attacks?)
  • in my opinion, it's too much work to use sqli in complicated cases (see link)

PDO不能解决所有这些问题.问题是SQL注入:如果不使用参数化查询,PDO将如何帮助SQL注入?

PDO does not solve any of these problems. The issue is SQL injection: how does PDO help with SQL Injection if you do not use paramaterized queries?

记住,用PHP编写了一个MySQL小库,可以简单有效地完成这项工作.参见 https://github.com/bangkok-maco/MySQL-sql-injection-预防

That in mind, wrote a little library for MySQL in PHP that does the job simply and effectively. See https://github.com/bangkok-maco/MySQL-sql-injection-prevention

(有人乐于将库放在这里,但用 REAME 上使用介绍网站.)

(Someone helpfully put the library here but replacing it with link, but please use the REAME on the site for introduction.)

问题是,我知道基本原则是否足以解决需要解决的问题.

The problem is, I do know know whether the base tenets solve enough of the problem needing solving.

以下是宗旨:

  • 每个SELECT是由没有DML(INSERT,UPDATE,DELETE)权限的用户执行的.
  • DML语句仅返回受影响的行数
  • 除非通过MySQL函数和过程,否则无法访问敏感数据
  • 影子用户,没有其他人可以执行这些功能,并且没有其他权限
  • DMLI语句已参数化; SELECT语句永远不会参数化
  • each SELECT is executed by a user with no DML (INSERT, UPDATE, DELETE) rights
  • a DML statement returns only the number of affected rows
  • sensitive data is inaccessible except through MySQL functions and procedures
  • a shadow user and no one else may execute these functions and has no other rights
  • DML statements are parameterized; SELECT statements are never parameterized

从逻辑上讲,够了吗?

SQL注入会导致非法的SELECT(可以简单地将其吃掉),但是SELECT不能写入任何数据. DML是参数化的,因此数据是标量的.普通密码或普通用户根本无法访问敏感数据(例如密码).

A SQL Injection can result in an illegal SELECT (which can be simply eaten), but that SELECT can write no data. DML is paramaterized, so that data is scalar. Sensitive data, eg, passwords, are simply not accessible through ordinary SQL or through ordinary users.

推荐答案

此代码像筛子一样漏水.
您正在一个看不见mysql_real_escape_string()的函数中调用mysql_query.
您正在其他功能中使用PDO.
这是一团糟,没有道理. 如果您知道如何使用PDO,请使用它.
这样您就可以安全了.

This code is as leaky as a sieve.
You are calling mysql_query in one function with no mysql_real_escape_string() in sight.
You are using PDO in another function.
This is a mess and makes no sense. If you know how to use PDO, just use that.
Then you will be safe.

如果要使用mysql_query,则必须使用mysql_real_escape_string().

If you want to use mysql_query, you have to use mysql_real_escape_string().

这篇关于使用MySQL重新进行SQL注入攻击,基线要求是什么?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆