intro

每个人都会犯错,知错能改善莫大焉.
路怎么走,你们自己挑.

本文不提及具体代码细节和挖洞细节,如想了解漏洞,学习OWASP TOP10

bug

总结去年挖到的不少bug,得罪不少人,也坑了师爷,深表歉意.

挖到和钱有关的bug我也不记得有多少个了.

越权访问,信手拈来,简单到不愿意挖

提升管理员权限,偶然review之前自己写代码的时候发现别人的代码有问题

CSRF/跨站有点麻烦,组合拳实现

安全误配置,泄露网站物理路径.偶然测试发现.(有人会说这个有毛用?这个一会再展开)

限制失败,伪造IP,伪造UA.这个太简单了…

重定向和跨域,偶然测试发现…

任意命令执行 全局搜索,细读每一行"问题"函数.

(但现在并未成功,代码一定是有问题的,等着谁改坏的时候就可以嘿嘿嘿了)

公网无法访问的SQLi

恶意代码导致客户端Crash

敏感细信泄露也很多

细数每个bug其实都很简单,归结为以下几点:

1、参数没校验!

2、少校验了一个参数!!

3、忘记校验参数1与参数2之间的关系!!!

4、参数校验的不对!!!!

show

偶然间发现了后台有一处鸡肋xxs,只有自己登录的账号才能触发.是不是很鸡肋.

这个时候有人会说,有什么用.我凭什么修复..

(后来不知道谁把这个bug给报了,真的修复了….)

imgs

既然无法访问,今天心血来潮又测了一波之前发现的一处bug是否修复妥当.修是修了,但是没有修复妥当.

导致了鸡肋的xss就变成了所有人都可访问的存储型xss….

imgs
泄露网站物理路径

物理路径泄露最多算是配置不当,导致的敏感信息泄露.

但是SQLi+物理路径可以写shell!可以写shell!!

你知道多少人就差物理路径就拿到网站权限了??

不是没有用,而是你不了解网络安全,不重视网络安全!

前几天就复现了这一套基本的组合拳,二者缺一不可.不放地址和截图了.

kill the bug

验一个参数是有多难吗?嗯!很难!!真的很难!!!

在我把每一次接口调用的人都想象成是坏人的话,摁.好难啊!!!

这么多参数需要验…每个都验,代码非常不美观.因为抽象程度不够/需求迭代频繁.

人与人之间的信任呢?

前端与后端之间的信任呢?

哪怕再复杂,也需要验证关键参数. 验!参!!!

调用非自己写的接口时,也要注意查看返回类型,返回数据结构.

也许哪一天就被"坑"了.

使用强类型校验,指定数据类型

判断为空不要仅用empty(),要验证关键参数例如id为空的情况!!

不坑自己也别坑他人.

发表评论

电子邮件地址不会被公开。 必填项已用*标注