我一直在各地寻找尝试找到解决方案。我最近在我们的网站上运行扫描,以查找XSS和SQL注入的任何漏洞。有些项目引起了我的注意。
用户输入的任何数据现在都使用filter_var()进行验证和清理。
我现在的问题是XSS和操纵URL的人。似乎无处不在的简单的是:
http://www.domainname.com/script.php/">< script>alert('xss');< /script >
这会更改一些$_SERVER
变量并导致我的所有CSS,链接,图像等的相对路径无效,并且页面无法正确加载。
我清理脚本中使用的所有变量,但我不确定如何在URL中删除这些不需要的数据。
提前致谢。
增加: 然后,这会在模板文件中生成一个简单的链接:
<a href="anotherpage.php">Link</a>
实际链接到:
“http://www.domainname.com/script.php/” &GT;&LT;脚本&GT;警报( 'XSS');&LT; / script&gt; /anotherpage.php
答案 0 :(得分:2)
这会改变一些
$_SERVER
变量并导致我的所有CSS,链接,图像等的相对路径无效,并且页面无法正确加载。
这听起来你在网站上犯了大错,应该重新思考如何将输入中的链接信息注入到输出中。
单独过滤输入在这里没有帮助,您还需要过滤输出。
如果您的应用程序收到的请求与允许的请求的超集不匹配,则返回404错误通常会更容易。
我不确定如何在网址中删除这些不需要的数据。
实际上,请求已经发送,因此设置了URL。你不能“改变”它。这只是所要求的信息。
现在你应该处理它,而不是盲目地将它传递给它,例如进入你的输出(然后你的链接被破坏)。
编辑:您现在更具体地写了您所关注的内容。我会在dqhendricks进入一个:谁在乎呢?
如果您对用户只是使用她的浏览器并输入任何URL这一事实感到不舒服,那么她可以自由地做到这一点,技术上正确的答案是:
400 Bad Request(ref)
返回一个没有或只有完全限定URI(绝对URI)或重新定义 Base-URI 的页面,否则浏览器会将输入的URI作为< EM>基础-URI 。请参阅Uniform Resource Identifier (URI): Generic Syntax RFC 3986; Section 5. Reference ResolutionSpecs。
答案 1 :(得分:1)
首先,如果有人将垃圾添加到他们的网址,谁会关心网页是否正确加载图片?如果请求无效,为什么会加载任何页面?你为什么要使用SERVER vars获取路径呢?
第二,您还应该使用适合您特定数据库的方法转义任何用户提交的数据库输入,以避免sql注入。 filter_var通常无济于事。
第三,xss很容易保护。任何用户提交的要在任何页面上显示的数据都需要使用htmlspecialchars()进行转义。如果您使用可以构建此转义的视图类,则更容易确保。
答案 2 :(得分:0)
您对XSS的担忧:除非您盲目使用相关的$ _SERVER变量,否则更改的URL不会进入您的页面。相对链接似乎包含URL注入脚本这一事实是一种浏览器行为,只会破坏您的相对链接。由于您没有使用$ _SERVER变量进行盲注,因此您不必担心。
关注您的相对路径:不要使用相对路径。使用至少一个域根路径(以斜杠开头)引用所有资源,这种URL损坏不会以您描述的方式破坏您的网站。