trhimily

导航

< 2025年3月 >
23 24 25 26 27 28 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 1 2 3 4 5
统计
 

web测试安全性常见问题

                

一、             登录账号明文传输

1、  问题一:登录账号密码或者修改密码明文传输

现象:目前物流对内的java系统基本上都是明文传输用户名和密码的

使用火狐自带工具-开发者-网络,或者httpwatch工具很容易获取到信息

打开工具后进行被测系统正常登录软件可自动获取信息

                       

 

建议:

登录使用加密传输,一般的登录都采用https方式加密协议

2、  问题二:在后台日志中明文打印出了登录的账号和密码

现象:

建议:在日志中比较敏感的信息比如密码都采用*转换显示

 

二、             SQL注入

1、  问题一:部分查询输入存在SQL注入风险

所谓SQL注入式攻击,就是攻击者把SQL命令插入到Web表单的输入域或页面请求的查询字符串,欺骗服务器执行恶意的SQL命令。在某些表单中,用户输入的内容直接用来构造(或者影响)动态SQL命令,或作为存储过程的输入参数,这类表单特别容易受到SQL注入式攻击。

现象一:

原登录页面的sql:

SELECT COUNT(*) FROM Login WHERE UserName='admin' AND Password='123456'

现在登录时输入:’admin’--

SELECT COUNT(*) FROM Login WHERE UserName='admin'-- Password='123'

因为UserName值中输入了“--”注释符,后面语句被省略而登录成功。(常常的手法:前面加上'; ' (分号,用于结束前一条语句),后边加上'--' (用于注释后边的语句))

现象二:在查询语句中输入:’ or ‘1=1  看是否会查询出所有的记录

建议:开发不要直接写静态sql语句进行查询,需要使用动态拼接SQL,对于web测试需要对查询部位进行SQL注入测试。

注:参数化查询原理:在使用参数化查询的情况下,数据库服务器不会将参数的内容视为SQL指令的一部份来处理,而是在数据库完成 SQL 指令的编译后,才套用参数运行,因此就算参数中含有具有损的指令,也不会被数据库所运行。

三、             XSS跨站点攻击

1、  问题一:部分系统存在提交表单时输入html代码和JS代码可在服务器执行的情况

跨站脚本攻击(Cross Site Scripting)恶意攻击者往Web页面里插入恶意Script代码,当用户浏览该页之时,嵌入其中Web里面的Script代码会被执行,从而达到恶意攻击用户的特殊目的,如:

<input>

<script>alert('xss')</script>

 

现象:文本框中输入<input>或<script>alert('xss')</script>

 

提交后<input>和<script>alert('xss')</script>作为代码执行了出现了输入框,而不是作为字符串存储

 

建议:

原则:不相信客户输入的数据
注意: 攻击代码不一定在<script></script>中,还有其他方式

1)只允许用户输入我们期望的数据。 例如: 年龄的textbox中,只允许用户输入数字。 而数字之外的字符都过滤掉。

2)对数据进行Html Encode 处理

3)过滤或移除或转义特殊的Html标签, 例如: <script>, <iframe> , &lt; for <, &gt; for >, &quot for

 

四、             跨站伪造

1、  问题一:构造POST请求进行请求可提交到数据库中

是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法,也是可以从第三方网站提交的

现象:如下脚步用户获取到请求地址后,可以自己构造请求消息请求参数和值,通过浏览器执行后也可以提交到数据库那说明就是存在跨站伪造

 

建议:

Token验证

在每个HTTP请求里附加一部分信息是一个防御CSRF攻击的很好的方法,因为这样可以判断请求是否已经授权。这个“验证token”应该不能轻易的被未登录的用户猜测出来。如果请求里面没有这个验证token或者token不能匹配的话,服务器应该拒绝这个请求。

 

五、             目前普遍现象Java层未做校验或未做全部校验

一般来说JS的校验都是一种辅助,实际校验都要放在服务器,如果不做JAVA校验就可能会存在

1)  使用WebSarab等代理工具绕过页面校验,直接篡改数据后往数据库中插入数据;

2)  html层的校验不能防止用户伪造请求 ,如上面的token校验就是其中一个例子;

3)  按ctrl+f5强制刷新提交,出现重复提交

4)  js需要浏览器下载,如果浏览器下载JS失败,按钮未灰化用户可以反复点击,可出现重复提交,那还得靠服务器端的重复提交来保证

 

六、             借用WebSarab工具来绕过客户端的校验,验证是否进行了服务校验

七、             借用AppScan工具来自动扫描安全性问题

posted on   trhimily  阅读(699)  评论(0编辑  收藏  举报
编辑推荐:
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识(上)
阅读排行:
· 阿里最新开源QwQ-32B,效果媲美deepseek-r1满血版,部署成本又又又降低了!
· 单线程的Redis速度为什么快?
· SQL Server 2025 AI相关能力初探
· 展开说说关于C#中ORM框架的用法!
· AI编程工具终极对决:字节Trae VS Cursor,谁才是开发者新宠?
 
点击右上角即可分享
微信分享提示