MSSQL中的SA权限，其重要性不言而喻——它相当于数据库层面的“超级管理员”账户。本文重点探讨的是如何利用SA权限结合NBSI工具的上传功能，一步步获取WebShell。但在实战之前，必须满足几个关键前提条件，否则这一攻击路径无法实现。

前提条件非常明确：

首先，目标站点必须存在SQL注入点，并且数据库类型为MSSQL；其次，连接数据库的账户权限必须是SA；最后，后台系统必须提供文件上传功能。

下面直接用一个具体案例来说明。假设目标网址为：hxxp://www.6x36x.com/fangchan/listpro.asp?id=53，使用NBSI扫描后，结果一目了然——数据库为MSSQL，当前权限为SA。那么第三个条件如何验证？观察页面中的文章或新闻内容，查找图片链接地址。例如，发现一张图片的链接是hxxp://www.6x36x.com/admin/uploadpic/2xx5042823082994329.gif，这就表明后台必然存在文件上传功能。

接下来需要获取网站的真实物理路径。这一步完全依赖NBSI的NB Commander功能（或NB Tree_List）。推荐使用NB Commander，具体原因稍后揭晓。寻找路径确实需要耗费一些时间，考验的是耐心和细致。只要肯下功夫，最终总能找到。本例中，我找到了目标站点的路径：D:\9x3x9。

然后就是后台登录入口。很快定位到Admin/login.asp。接下来自然是尝试猜解账号和密码。但这次运气不佳，多次尝试均未成功。难道账号密码为空？尝试使用空密码登录，结果依然失败。

从这一步开始，NB Commander的功能就显得至关重要。因为列目录操作，无论是NB Commander还是NB Tree_List都能胜任。我找到文件conn.asp，使用命令type D:\9x3x9\admin\login.asp查看源代码。代码逻辑并无异常，使用的是admin表，字段也完全匹配。但为何始终无法登录？如果有清楚原因的朋友，欢迎指点，帮助我这个新手走出困惑。

无法进入后台，自然无法上传图片。我尝试过NBSI的上传功能，但未能成功。上传后发现，代码的每一行都重复出现了三次，原因不明。使用臭要饭的Getwebshell工具也遇到同样的问题。

换个思路，分析一下它的Session验证机制。通过type D:\9x3x9\admin\quanxian.asp命令，很快发现——它为Session(“wsl”)赋值为1。于是，我编写了一个非常简单的程序，利用NBSI的上传功能将其上传。无论重复多少次，应该都是正确的。上传后保存为1.asp，然后访问hxxp://www.6x36x.com/admin/1.asp，接着访问hxxp://www.6x36x.com/admin/admin_index.asp，就这样成功进入了后台。本地测试也顺利通过。

顺便提一下，Session变量与cookies本质上属于同一类机制。如果用户浏览器设置不接受任何cookie，那么Session变量将无法正常工作。用户访问页面时，每个Session变量会自动生成，离开页面后仍会保留20分钟——这个时间由Web服务器管理员决定。有些站点只保留3分钟，有些是10分钟，默认值为20分钟。如果Session中存储了较大的对象（例如ADO recordsets、connections），随着站点访问量增加，服务器可能会不堪重负。此外，Session变量创建过于随意，容易导致代码难以阅读和维护。

成功进入后台后，找到图片上传位置，将asp木马文件修改后缀为.gif后上传。务必记住上传后的文件名——这里是uploadpic\2xx56171430123.gif。接下来怎么做？将图片复制为.asp，或者直接重命名为.asp即可。

至此，木马已经成功上传。后续操作就不再赘述了。

总结一下：SA权限确实是数据库安全的一大隐患。程序员在连接MSSQL数据库时，绝对不要使用SA账户，否则服务器沦陷的风险极高。另外，MSSQL的扩展存储功能，如果用不上就及时删除，否则只会成为黑客攻击的利器。