目录遍历，敏感信息泄露，不安全的URL跳转
目录遍历漏洞
概述
在web功能设计中,很多时候我们会要将需要访问的文件定义成变量，从而让前端的功能便的更加灵活。 当用户发起一个前端的请求时，便会将请求的这个文件的值(比如文件名称)传递到后台，后台再执行其对应的文件。 在这个过程中，如果后台没有对前端传进来的值进行严格的安全考虑，则攻击者可能会通过“…/”这样的手段让后台打开或者执行一些其他的文件。 从而导致后台服务器上其他目录的文件结果被遍历出来，形成目录遍历漏洞。
看到这里,你可能会觉得目录遍历漏洞和不安全的文件下载，甚至文件包含漏洞有差不多的意思，是的，目录遍历漏洞形成的最主要的原因跟这两者一样，都是在功能设计中将要操作的文件使用变量的 方式传递给了后台，而又没有进行严格的安全考虑而造成的，只是出现的位置所展现的现象不一样，因此，这里还是单独拿出来定义一下。
需要区分一下的是,如果你通过不带参数的url（比如：http://xxxx/doc）列出了doc文件夹里面所有的文件，这种情况，我们成为敏感信息泄露。 而并不归为目录遍历漏洞。（关于敏感信息泄露你你可以在"i can see you ABC"中了解更多）
你可以通过“…/…/”对应的测试栏目，来进一步的了解该漏洞。
靶场
这里有超链接，我们点一下
这里出现了一些内容，我们看一下URL里，可以发现它传的是一个文件名到后台，后台对这个文件进行读取。然后我们可以来操作一下，我们可以把这个文件名换成…/只要…/足够多，他就会跳到根路径下，我们再以根路径为起始点去读取其他的文件。
目录遍历实际上也是前端传进去的文件和路径到后端之后它没有进行严格的处理，然后直接拼接到了路径里面导致我们可以通过…/来去获取一些非预期的文件。
这个漏洞看起来会和我们之前的文件包含和不安全的文件下载有点像，其实它们的形成的原因是一样的。
敏感信息泄露
概述
由于后台人员的疏忽或者不当的设计，导致不应该被前端用户看到的数据被轻易的访问到。 比如：
-
通过访问url下的目录，可以直接列出目录下的文件列表;
-
输入错误的url参数后报错信息里面包含操作系统、中间件、开发语言的版本或其他信息;
-
前端的源码（html,css,js）里面包含了敏感信息，比如后台登录地址、内网接口信息、甚至账号密码等;
类似以上这些情况，我们成为敏感信息泄露。敏感信息泄露虽然一直被评为危害比较低的漏洞，但这些敏感信息往往给攻击着实施进一步的攻击提供很大的帮助,甚至“离谱”的敏感信息泄露也会直接造成严重的损失。 因此,在web应用的开发上，除了要进行安全的代码编写，也需要注意对敏感信息的合理处理。
靶场
这里有一个登录页面，一般来说我们的开发人员，在写完代码之后，他应改把它相关的注释都删除掉，如果说他把一些重要的信息写到代码里面，可能就会被前端的用户发现。
我们这里右键查看页面源码，搜索“测试”
这里有一个测试账号，可能是开发人员用于自己测试的，但是他可能不会想到用户可以在前端看到，这样就把这个账号密码泄露出来了，这只是一个方面。
cookie设置不当也会产生漏洞，下面我们先进行一个登录
我们可以看到登陆以后，这里有一个页面。我们打开开发者选项
这里可以看到cookie里有一个密码，虽然它进行了hash，但是他这样显示在前端是不妥的。如果你的hash算法非常弱，别人拿到这个值，用彩虹表去撞一下，很可能就能拿到lucy对应的密码。
不安全的URL跳转
概述
不安全的URL跳转问题可能发生在一切执行了URL地址跳转的地方。
如果后端采用了前端传进来的（可能是用户传参，或者之前预埋在前端页面的URL地址）参数作为了跳转的目的地，而又没有做判断的话，就可能发生"跳错对象"的问题。
URL跳转比较直接的危害是:
–>钓鱼，既攻击者使用漏洞方的域名（比如一个比较出名的公司域名往往会让用户放心的点击）做掩盖，而最终跳转的确实钓鱼网站
靶场
这里有几个超链接，我们挨着点一下。
我们可以看到前两个是没有反应的，而第四个会弹出一句话，第三个发生了一个跳转，跳回到了我们的概述页面。
我们可以来试着改一下URL，我们换成http://www.baidu.com
我们可以看到它直接跳到百度去了，如果这时我们把它改成自己构造的一个恶意站点的话，把整个URL发送给用户，用户就可能会被前面的可信网站欺骗，从而点开跳到我们构造的恶意网站。
我们来看一下后台代码：
他直接通过get请求获取到了前端传入的URL，然后判断这个URL如果等于i，他就会说好的，希望你能坚持做自己！如果不等于i，它就直接用locatiuon对URL进行了跳转，这样就出现了一个恶意URL跳转的问题。
t请求获取到了前端传入的URL，然后判断这个URL如果等于i，他就会说好的，希望你能坚持做自己！如果不等于i，它就直接用locatiuon对URL进行了跳转，这样就出现了一个恶意URL跳转的问题。
我们后台一定要注重URL重定向的功能设计，我们需要对URL做一个白名单的限制，这样是比较合适的做法，如果什么都不做就很容易产生这种问题，从而被人拿去做钓鱼。
