为什么php框架限制url字符[重复]

时间：2022-06-08 07:48:23

This question already has an answer here:

这个问题在这里已有答案:

I have been searching for why this is true (from codeigniter's default config file).

我一直在搜索为什么这是真的(来自codeigniter的默认配置文件)。

I want to know why codeigniter acts like this URL sanitization is so important. Not to turn it off, but for the sake of curiosity and to know if its OK to use frameworks that don't have this feature.

我想知道为什么codeigniter就像这个URL清理一样非常重要。不要把它关闭,但为了好奇,并知道它是否可以使用没有此功能的框架。

/*
|--------------------------------------------------------------------------
| Allowed URL Characters
|--------------------------------------------------------------------------
|
| This lets you specify with a regular expression which characters are permitted
| within your URLs.  When someone tries to submit a URL with disallowed
| characters they will get a warning message.
|
| As a security measure you are STRONGLY encouraged to restrict URLs to
| as few characters as possible.  By default only these are allowed: a-z 0-9~%.:_-
|
| Leave blank to allow all characters -- but only if you are insane.
|
| DO NOT CHANGE THIS UNLESS YOU FULLY UNDERSTAND THE REPERCUSSIONS!!
|
*/

The only reasons I've seen so far have been:

我到目前为止看到的唯一原因是:

  1. hackers are inventive so don't turn it off

    2. 黑客是有创造力的,所以不要把它关掉

  2. prevent users from sql injection

    3. 防止用户sql注入

  3. prevent spoofing to different sites such as http://yoursite.com@hacker.com

    4. 防止欺骗到不同的网站,如http://yoursite.com@hacker.com

  4. for URL encoding

    5. 用于URL编码

  5. whitelists are better than blacklists

    6. 白名单优于黑名单

The first and fifth reasons are basically non-sequiters. Why URLs? If funky URLs don't have security issues, they don't need a blacklist so they don't need this whitelist. If strange URL aren't capable of hacking your site, it would be a wonderful waste of their time to allow their inventive harmless experimentation rather than force them to move onto something actually capable of revealing security holes.

第一和第五个原因基本上是非选区。为什么网址?如果时髦的URL没有安全问题,则不需要黑名单,因此他们不需要此白名单。如果奇怪的URL不能破解你的网站,那么浪费他们的时间来允许他们创造性的无害实验,而不是强迫他们转移到真正能够揭示安全漏洞的东西上。

The second reason is flawed for two reasons; firstly this sanitization isn't used on the query string or POST data which is where you'd expect to find most injection attempts. Secondly, this doesn't escape these characters, it denies any request including them. I would be upset as a user if Stack Overflow killed by pageload because my post included an apostrophe.

第二个原因有缺陷有两个原因;首先,这个清理不会用在查询字符串或POST数据上,这是您希望找到大多数注入尝试的地方。其次,这并没有逃脱这些角色,它否认任何包括它们在内的请求。如果Stack Overflow因页面加载而被杀,我会因为用户而感到不安,因为我的帖子包含了撇号。

Reasons three and four simply don't apply. Reason three is that users will think they are going to yoursite.com and actually end up in hacker.com. There is nothing you can do to prevent this, you never receive the request. Similarly, number 4 seems to be led by the misunderstanding that this is generating URLs rather than parsing them. This code is parsing what you can be certain is by this point a valid URL. Codeigniter decodes the URI characters before running this regex.

原因三和四根本不适用。原因三是用户会认为他们会访问yoursite.com并最终进入hacker.com。您无法阻止此操作,您永远不会收到请求。同样,数字4似乎是由于误解这是生成URL而不是解析它们而导致的。此代码解析了您可以确定的有效URL。 Codeigniter在运行此正则表达式之前解码URI字符。

So those are the answers I have heard and I either don't understand them, or there is a real reason out there I have yet to find, or the code is mostly useless. Any security experts out there who can enlighten me?

所以这些是我听到的答案,我要么不理解它们,要么就是有一个我尚未找到的真正原因,或者代码几乎没用。有谁可以开导我的安全专家?

1 个解决方案

#1

1  

Image. If you wrote a framework that was consistently compromised because of poor coding practices of the coders, then you're not going to have a successful framework. Once the marketing image has been tainted, it's not easy to explain "It's the CODERS fault!". A successful framework isn't compromised and provides by default a base set of security enhancements. Personally, I'd much rather start with a locked down framework and only compromise specific areas than have a framework that's often attacked because of their known vulnerabilities (that's how frameworks end up on known exploits lists)

图片。如果你编写的框架由于编码器的编码实践不良而一直受到损害,那么你就不会有一个成功的框架。一旦营销形象受到污染,就不容易解释“这是CODERS的错误!”。成功的框架不会受到损害,默认情况下会提供一组基本的安全增强功能。就个人而言,我更倾向于从一个锁定的框架开始,只是破坏特定区域,而不是因为已知漏洞而经常受到攻击的框架(这就是框架最终在已知的漏洞利用列表中)

#1

1  

Image. If you wrote a framework that was consistently compromised because of poor coding practices of the coders, then you're not going to have a successful framework. Once the marketing image has been tainted, it's not easy to explain "It's the CODERS fault!". A successful framework isn't compromised and provides by default a base set of security enhancements. Personally, I'd much rather start with a locked down framework and only compromise specific areas than have a framework that's often attacked because of their known vulnerabilities (that's how frameworks end up on known exploits lists)

图片。如果你编写的框架由于编码器的编码实践不良而一直受到损害,那么你就不会有一个成功的框架。一旦营销形象受到污染,就不容易解释“这是CODERS的错误!”。成功的框架不会受到损害,默认情况下会提供一组基本的安全增强功能。就个人而言,我更倾向于从一个锁定的框架开始,只是破坏特定区域,而不是因为已知漏洞而经常受到攻击的框架(这就是框架最终在已知的漏洞利用列表中)

标签：

相关文章