编码时我需要考虑哪些安全问题？

18

OWASP.org保留一个列表。从OWASP top ten开始。

来源

2008-11-04 15:29:26

1

Buffer overflows是经典的，如果你写C，因为他们经常允许攻击者执行任意代码。

来源

2008-11-04 15:25:06

1

这是网络的东西，但自从你离开它开放式的......

JavaScript注入。如果您允许任何来自输出源的输入，则可以在输入中输入JavaScript，然后在输出时（除非正确编码/解码），它将输出原始javascript。

来源

2008-11-04 15:27:31

0

发送纯文本密码而不先加密它们绝不是一个好主意。

来源

2008-11-04 15:27:59 Robert

0

避免发送纯文本用户名。

来源

2008-11-04 15:28:29 Robert

+0

坏人知道的信息越少越好。如果您已经对密码进行加密/散列处理，为什么不对用户名执行相同操作？ – Robert 2009-04-15 15:26:44

6

从不存储明文密码。（我无法告诉你我为我的公司评估了多少商业软件包，然后在我给他们打电话时对其采取了冷静措施。我最喜欢的一个来自CRM供应商的借口：“您的最终用户通常会拥有企业管理器或查询分析器在他们的桌面上？“）

来源

2008-11-04 15:29:17

0

如何验证用户输入？例如，你期待一个10位数的电话号码，但你会得到“800OHNOES！”

来源

2008-11-04 15:30:31 warren

3

Here是十大安全编码实践的列表。这是一个很好的开始。考虑＃8，特别是深度防御。

来源

2008-11-04 16:17:00 Flory

+0

我发现“防御深度”经常被用作图层中漏洞的借口。 “这是一个漏洞。” “是的，但我不打算修复它，因为我们练习纵深防御。”没有深度;单独考虑每一层。 – erickson 2008-11-04 17:46:29

+0

是的，这听起来像防御层上面有一层败类。 – Flory 2008-11-04 18:14:45

2

在处理之前按摩并过滤所有输入到您的程序。

切勿在不进行筛选和截断的情况下处理输入。

-R

来源

2008-11-04 16:46:54 Huntrods

+0

或者更一般地说，不要相信用户。 – 2008-11-10 07:23:23

1

你可以考虑这本书的章节是一个相当不错的清单...

19 Deadly Sins of Software Security

来源

2008-11-04 16:52:03 Martin

1

简单的防守编程。对于每个函数/方法/过程/子例程，请考虑“什么是预期输入？当输入偏离该输入时该怎么办？我怎样才能最轻松地确保输入不会偏离该输入。”了解你的意见;知道你的输出。不要太过分，而且要明白数据库中的数据可能已经被破坏。如果某个特定的数据集可以用某种特定的方式进行约束，那么选择你的数据类型和变量来播放。保持数字的东西数字。

每当我在程序中看到一个字符串对象时，我都会问：“如果这个字符串包含Gilbert和Sullivan歌曲的歌词会发生什么？简单的if-else检查和函数开头的提前返回语句可以防止这类事件在后期造成严重破坏。

来源

2008-11-05 00:04:27 Omniwombat

11

其他人都说过这个，但是...

基本上所有的安全漏洞都来自于数据。如果你的程序没有处理任何数据，它可能是安全的。它也可能是相当无用的:)。

这导致我认为是什么使代码安全的核心理念：

不要相信你的数据。永远。

消毒所有可能的东西。你可以依赖你的平台的安全保证（例如，你很可能看不到像Java或C＃这样的托管语言中经典的基于字符串的缓冲区溢出），但是否则你需要验证应用程序中的所有内容。

来源

2008-11-10 06:53:25

0