浅谈为什么#{}可以防止SQL注入

目录
  • #{} 和 ${} 的区别
    • #{} 底层是如何防止 SQL 注入的?
  • 为什么能防止SQL注入?

#{} 和 ${} 的区别

#{} 匹配的是一个占位符,相当于 JDBC 中的一个?,会对一些敏感字符进行过滤,编译过后会对传递的值加上双引号,因此可以防止 SQL 注入问题。

${} 匹配的是真实传递的值,传递过后,会与 SQL 语句进行字符串拼接。${} 会与其他 SQL 进行字符串拼接,无法防止 SQL 注入问题。

<mapper namespace="com.gitee.shiayanga.mybatis.wildcard.dao.UserDao">
    <select id="findByUsername" resultType="com.gitee.shiayanga.mybatis.wildcard.entity.User" parameterType="string">
        select * from user where username like #{userName}
    </select>
    <select id="findByUsername2" resultType="com.gitee.shiayanga.mybatis.wildcard.entity.User" parameterType="string">
        select * from user where username like '%${userName}%'
    </select>
</mapper>
==>  Preparing: select * from user where username like ?
==> Parameters: '%小%' or 1=1 --(String)
<==      Total: 0
==>  Preparing: select * from user where username like '%aaa' or 1=1 -- %'
==> Parameters:
<==      Total: 4

#{} 底层是如何防止 SQL 注入的?

  • #{} 底层采用的是 PreparedStatement,因此不会产生 SQL 注入问题
  • #{} 不会产生字符串拼接,而 ${} 会产生字符串拼接

为什么能防止SQL注入?

以MySQL为例,#{} 使用的是 com.mysql.cj.ClientPreparedQueryBindings#setString 方法,在这里会对一些特殊字符进行处理:

public void setString(int parameterIndex, String x) {
        if (x == null) {
            setNull(parameterIndex);
        } else {
            int stringLength = x.length();

            if (this.session.getServerSession().isNoBackslashEscapesSet()) {
                // Scan for any nasty chars

                boolean needsHexEscape = isEscapeNeededForString(x, stringLength);

                if (!needsHexEscape) {
                    StringBuilder quotedString = new StringBuilder(x.length() + 2);
                    quotedString.append('\'');
                    quotedString.append(x);
                    quotedString.append('\'');

                    byte[] parameterAsBytes = this.isLoadDataQuery ? StringUtils.getBytes(quotedString.toString())
                            : StringUtils.getBytes(quotedString.toString(), this.charEncoding);
                    setValue(parameterIndex, parameterAsBytes, MysqlType.VARCHAR);

                } else {
                    byte[] parameterAsBytes = this.isLoadDataQuery ? StringUtils.getBytes(x) : StringUtils.getBytes(x, this.charEncoding);
                    setBytes(parameterIndex, parameterAsBytes);
                }

                return;
            }

            String parameterAsString = x;
            boolean needsQuoted = true;

            if (this.isLoadDataQuery || isEscapeNeededForString(x, stringLength)) {
                needsQuoted = false; // saves an allocation later

                StringBuilder buf = new StringBuilder((int) (x.length() * 1.1));

                buf.append('\'');

                //
                // Note: buf.append(char) is _faster_ than appending in blocks, because the block append requires a System.arraycopy().... go figure...
                //

                for (int i = 0; i < stringLength; ++i) {
                    char c = x.charAt(i);

                    switch (c) {
                        case 0: /* Must be escaped for 'mysql' */
                            buf.append('\\');
                            buf.append('0');
                            break;
                        case '\n': /* Must be escaped for logs */
                            buf.append('\\');
                            buf.append('n');
                            break;
                        case '\r':
                            buf.append('\\');
                            buf.append('r');
                            break;
                        case '\\':
                            buf.append('\\');
                            buf.append('\\');
                            break;
                        case '\'':
                            buf.append('\'');
                            buf.append('\'');
                            break;
                        case '"': /* Better safe than sorry */
                            if (this.session.getServerSession().useAnsiQuotedIdentifiers()) {
                                buf.append('\\');
                            }
                            buf.append('"');
                            break;
                        case '\032': /* This gives problems on Win32 */
                            buf.append('\\');
                            buf.append('Z');
                            break;
                        case '\u00a5':
                        case '\u20a9':
                            // escape characters interpreted as backslash by mysql
                            if (this.charsetEncoder != null) {
                                CharBuffer cbuf = CharBuffer.allocate(1);
                                ByteBuffer bbuf = ByteBuffer.allocate(1);
                                cbuf.put(c);
                                cbuf.position(0);
                                this.charsetEncoder.encode(cbuf, bbuf, true);
                                if (bbuf.get(0) == '\\') {
                                    buf.append('\\');
                                }
                            }
                            buf.append(c);
                            break;

                        default:
                            buf.append(c);
                    }
                }

                buf.append('\'');

                parameterAsString = buf.toString();
            }

            byte[] parameterAsBytes = this.isLoadDataQuery ? StringUtils.getBytes(parameterAsString)
                    : (needsQuoted ? StringUtils.getBytesWrapped(parameterAsString, '\'', '\'', this.charEncoding)
                            : StringUtils.getBytes(parameterAsString, this.charEncoding));

            setValue(parameterIndex, parameterAsBytes, MysqlType.VARCHAR);
        }
    }

所以 '%小%' or 1=1 --  经过处理之后就变成了 '''%小%'' or 1=1 --'

而 ${} 只是简单的拼接字符串,不做其他处理。

这样,它们就变成了:

-- %aaa' or 1=1 --
select * from user where username like '%aaa' or 1=1 -- %'

-- '%小%' or 1=1 --
select * from user where username like '''%小%'' or 1=1 --'

所以就避免了 SQL 注入的风险。

到此这篇关于浅谈为什么#{}可以防止SQL注入的文章就介绍到这了,更多相关#{}防止SQL注入内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • 如何有效防止sql注入的方法

    SQL注入攻击是黑客对数据库进行攻击常用的手段之一,随着B/S模式应用开发的发展,使用这种模式编写应用程序的程序员也越来越多.但是由于程序员的水平及经验参差不齐,相当大一部分程序员在编写代码的时候,没有对用户输入数据的合法性进行判断,使应用程序存在安全隐患.用户可以提交一段数据库查询代码,根据程序返回的结果,获得某些他想获取的数据,这就是所谓的SQL Injection,即SQL注入. 一 背景 假如某高校开发了一个网课系统,要求学生选课后完成学习,数据库中有一张表course,这张表存放着每个

  • 防止web项目中的SQL注入

    目录 一.SQL注入简介 二.SQL注入攻击的总体思路 三.SQL注入攻击实例 四.如何防御SQL注入 1.检查变量数据类型和格式 2.过滤特殊符号 3.绑定变量,使用预编译语句 小结: 一.SQL注入简介 SQL注入是比较常见的网络攻击方式之一,它不是利用操作系统的BUG来实现攻击,而是针对程序员编写时的疏忽,通过SQL语句,实现无账号登录,甚至篡改数据库. 二.SQL注入攻击的总体思路 1.寻找到SQL注入的位置 2.判断服务器类型和后台数据库类型 3.针对不同的服务器和数据库特点进行SQL

  • 有效防止sql注入的方法演示

    前言 SQL注入攻击是黑客对数据库进行攻击常用的手段之一,随着B/S模式应用开发的发展,使用这种模式编写应用程序的程序员也越来越多.但是由于程序员的水平及经验参差不齐,相当大一部分程序员在编写代码的时候,没有对用户输入数据的合法性进行判断,使应用程序存在安全隐患.用户可以提交一段数据库查询代码,根据程序返回的结果,获得某些他想获取的数据,这就是所谓的SQL Injection,即SQL注入. 一 背景 假如某高校开发了一个网课系统,要求学生选课后完成学习,数据库中有一张表course,这张表存放

  • 有效防止SQL注入的5种方法总结

    sql注入入门 SQL 注入是一类危害极大的攻击形式.虽然危害很大,但是防御却远远没有XSS那么困难. SQL 注入漏洞存在的原因,就是拼接 SQL 参数.也就是将用于输入的查询参数,直接拼接在 SQL 语句中,导致了SQL 注入漏洞. 演示下经典的SQL注入 我们看到:select id,no from user where id=2; 如果该语句是通过sql字符串拼接得到的,比如: String sql = "select id,no from user where id=" +

  • 浅谈为什么#{}可以防止SQL注入

    目录 #{} 和 ${} 的区别 #{} 底层是如何防止 SQL 注入的? 为什么能防止SQL注入? #{} 和 ${} 的区别 #{} 匹配的是一个占位符,相当于 JDBC 中的一个?,会对一些敏感字符进行过滤,编译过后会对传递的值加上双引号,因此可以防止 SQL 注入问题. ${} 匹配的是真实传递的值,传递过后,会与 SQL 语句进行字符串拼接.${} 会与其他 SQL 进行字符串拼接,无法防止 SQL 注入问题. <mapper namespace="com.gitee.shiay

  • 浅谈一次与sql注入 & webshell 的美丽“邂逅”

    引言 一波未平,一波又起.金融公司的业务实在是太引人耳目,何况我们公司的业处正处于风口之上(区块链金融),并且每天有大量现金交易,所以不知道有多少躲在暗处一直在盯着你的系统,让你防不胜防,并且想方设法的找到突破点,以达到的目的来获取非法利益. 俗话说:"道高一尺,魔高一丈".系统和代码也可以这么理解,防的在好,总有漏洞.系统和代码也没有绝对的安全.该来的总会来...... sql注入与"她"相遇 某一天,天气晴朗,心情舒畅."她"来了,打破了笔者

  • 浅谈lumen的自定义依赖注入

    比如我现在有个token认证系统,目前我用mysql的token表实现,将来有可能会改成redis,怎么实现未来的无缝连接呢. 先定义一个合约文件app/Contracts/TokenHandler.php <?php namespace App\Contracts; /** * 处理Token的Contracts * @package App\Contracts */ interface TokenHandler { /** * 创建一个token * @param $userId integ

  • Django 浅谈根据配置生成SQL语句的问题

    想要根据django中的模型和配置生成SQL语句,需要先进行一定的设置: 首先需要在你的app文件夹中进入setting.py文件,里面有一个DATABASES,进行设置数据库的配置信息: DATABASES = { 'default': { # 'ENGINE': 'django.db.backends.sqlite3', # 'NAME': os.path.join(BASE_DIR, 'db.sqlite3'), 'ENGINE': 'django.db.backends.mysql',

  • 浅谈MySQL中优化sql语句查询常用的30种方法

    1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引. 2.应尽量避免在 where 子句中使用!=或<>操作符,否则将引擎放弃使用索引而进行全表扫描. 3.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如: select id from t where num is null 可以在num上设置默认值0,确保表中num列没有null值,然后这样查询: select id from

  • 浅谈Vue项目骨架屏注入实践

    相比于早些年前后端代码紧密耦合.后端工程师还得写前端代码的时代,如今已发展到前后端分离,这种开发方式大大提升了前后端项目的可维护性与开发效率,让前后端工程师关注于自己的主业.然而在带来便利的同时,也带来了一些弊端,比如首屏渲染时间(FCP)因为首屏需要请求更多内容,比原来多了更多HTTP的往返时间(RTT),这造成了白屏,如果白屏时间过长,用户体验会大打折扣,如果用户网速差,则FCP会更长. 由此引申出一系列的优化方法,骨架屏也因此被提出. 1. FCP优化 在 Google 提出的以用户为中心

  • JSP 防范SQL注入攻击分析

    SQL注入攻击的总体思路: 发现SQL注入位置: 判断服务器类型和后台数据库类型: 确定可执行情况 对于有些攻击者而言,一般会采取sql注入法.下面我也谈一下自己关于sql注入法的感悟. 注入法: 从理论上说,认证网页中会有型如: select * from admin where username='XXX' and password='YYY' 的语句,若在正式运行此句之前,如果没有进行必要的字符过滤,则很容易实施SQL注入. 如在用户名文本框内输入:abc' or 1=1-- 在密码框内输

  • 浅谈mybatis中的#和$的区别 以及防止sql注入的方法

    mybatis中的#和$的区别 1. #将传入的数据都当成一个字符串,会对自动传入的数据加一个双引号.如:order by #user_id#,如果传入的值是111,那么解析成sql时的值为order by "111", 如果传入的值是id,则解析成的sql为order by "id". 2. $将传入的数据直接显示生成在sql中.如:order by $user_id$,如果传入的值是111,那么解析成sql时的值为order by user_id,  如果传入的

  • 浅谈三种数据库的 SQL 注入

    目录 SQL 注入原理 SQL 注入分类 1. 数字型注入 2. 字符型注入 3. 其他类型 常见数据库的注入 SQL Server MySQL Oracle SQL 注入原理 SQL注入攻击指的是通过构建特殊的输入作为参数传入Web应用程序,而这些输入大都是SQL语法里的一些组合,通过执行SQL语句进而执行攻击者所要的操作,其主要原因是程序没有细致地过滤用户输入的数据,致使非法数据侵入系统. SQL 注入分类 1. 数字型注入 当输入的参数为整型时,则有可能存在数字型注入漏洞. 假设存在一条

  • 浅谈开启magic_quote_gpc后的sql注入攻击与防范

    通过启用php.ini配置文件中的相关选项,就可以将大部分想利用SQL注入漏洞的骇客拒绝于门外. 开启magic_quote_gpc=on之后,能实现addslshes()和stripslashes()这两个函数的功能.在PHP4.0及以上的版本中,该选项默认情况下是开启的,所以在PHP4.0及以上的版本中,就算PHP程序中的参数没有进行过滤,PHP系统也会对每一个通过GET.POST.COOKIE方式传递的变量自动转换,换句话说,输入的注入攻击代码将会全部被转换,将给攻击者带来非常大的困难.

随机推荐