OK，终于到了实践的部分了。通过上面的分析，应该知道利用backup database来做一个shell是完全可行的，我们先来改写一下那个利用FSO的asp shell，使其能够符合我们的要求：<% Dim oscripq %><% Dim oscripqNet%>
拷贝c:l.asp到你的web发布目录，再用浏览器请求一下，没有500错误的话，你已经获得一个shell了，不过这个shell中垃圾数据实在是太多，你要多按几下TAB键才能到输入命令的那个输入框。 末了再说说可能出现的问题，一般来说随意选择一个数据库导出，默认情况下里面是不含有<%或者%>的，但也不排除有这种可能，尽管几率很小，但是我就遇到过一次。
如果以前没有动过model，导出的文件肯定是符合要求的，但是如果你中途如果写错了些东西，比如创建了一个表，内容有<%但是在同一行内没有%>出现的话，这个数据库就再也不能用了，因为也许是为了事务回滚的需要，即使你删除了这张表，在导出的文件中依然保存有这张表的原始内容，所以，千万要一次成功，错了就完了。
当然上面只是在查询分析器中的实验，实际情况下，如果你能以sa的身份注入，当然是比较轻松的，只是猜测web的物理路径的时候可能会稍微有一些麻烦，因为你得一次性导出到web的发布目录，不过也许你可以结合其他暴露物理路径的漏洞来利用。如果不是sa的身份的话，也许declare @a sysname;select @a=db_name()会有一些用处。
我假设你已经非常了解SQL Injection的基本概念。 【目标探测】当大多数人都意识到SQL Injection的威胁并进行一番修补之后，可能很难再找到下手的地方。但若想成功就必需要冷静耐心，当然有时也需要一点点运气；） 如果有源码，一定要耐心仔细地看。在一个庞大的系统中，是很难做到万无一失的。
而只要有一处漏洞，就足够威胁整个系统。千里之堤，溃于蚁穴。 这里主要总结一些Injection的高级用法。如何发现漏洞不是此篇主题，可参考我以前的一篇文章《发掘另类injection》 需要说明的是，Injection不只存在于web页面，应用程序也存在，绝不可以只见树木不见森林。
谢谢点赞
喜欢支持