保护 Web 服务器数据的最佳实践 [英] Best practices for keeping the web server data protected

问题描述

假设我经营一家医疗机构，并且想要一个网站，我的用户/患者可以在其中查找他们的私人记录.针对最常见攻击的最佳解决方案是什么?

Lets say I run a medical facility and want a website where my users/patients can lookup their private records. What would be the best solution against most-common attacks?

即使我使用从某处购买的私人服务器，并依赖其监控服务，也很有可能有人会发现安全漏洞并窃取我的数据.结束我的工作.

Even if I use a private server bought somewhere, and rely on its monitoring services there's a good chance someone could find a security hole and steal my data. End of my business.

这种架构的最佳做法是什么?

推荐答案

首先，您需要确定您想要尝试和防御的攻击，然后单独解决每个攻击.既然你提到了最常见的攻击"，我们就从那里开始；以下是常见的三层服务(客户端-网络-数据存储)的快速列表:

First you need to identify the attacks that you want to try and protect against, and then address each of them individually. Since you mention "most-common attacks", we will start there; here is a quick list for a common three-tiered service (client-web-datastore):

1. 损坏的输入(手动或模糊化)
2. SQL 注入
3. 跨站脚本攻击(XSS)
4. 猜测:蛮力、字典、彩虹表 等
5. 现场(员工)泄漏
6. 社会工程学
7. 中间人
8. 跨站点伪造攻击(CSRF)
9. 重放攻击

1. Corrupted Inputs (manual or fuzzed)
2. SQL Injection
3. Cross site scripting attacks (XSS)
4. Guessing: Brute force, dictionary, rainbow tables, etc.
5. Onsite (employee) leaks
6. Social engineering
7. Man-in-the-middle
8. Cross site forgery attacks (CSRF)
9. Replay attacks

一旦发生泄漏或破坏，这些是一些使攻击者更容易进行攻击的问题，因此也应予以解决:

Once a leak or breach happens, these are some of the issues that make it easier for the attackers, and thus should also be addressed:

• 以纯文本形式存储的数据
• 弱密码/密钥
• 弱加密或散列
• 禁止加盐
• 没有服务分离(例如，将数据库放置在与 Web 服务器相同的物理设备上)

现在我们来看看常见的缓解措施:

Now we look at common mitigations:

1-3(输入、SQL 注入、XSS) 处理大量错误输入.因此，需要对来自客户端的所有输入进行清理，并且需要执行(以攻击为中心的)测试以确保代码正常工作.

1-3 (Inputs, SQL Injection, XSS) deal a lot with bad inputs. So all inputs from a client need to be sanitized, and (attack-focused) testing needs to be performed to ensure the code works correctly.

4(猜测) 将使用自动化工具来尝试猜测用户的密码，或者如果他们已经拥有数据，他们将尝试强制使用密钥或散列.缓解措施涉及为加密或散列选择正确的算法.增加密钥的位大小.执行有关密码/密钥复杂性的政策.使用盐.限制每秒的尝试次数.等

4 (Guessing) Automated tools will be used to try and guess a users' password, or if they have the data already, they will try to force the key or hash. Mitigations involve choosing the correct algorithm for the encryption or hash. Increasing the bit size of the key. Enforcing policies on password/key complexity. Using salts. Limiting the number of attempts per second. etc.

5(泄漏)如果数据在现场加密，而管理员/员工/看门人没有解密数据的密钥，那么泄漏信息的价值有限(特别是如果#4 处理正确).您还可以限制访问数据的人员和方式(美国国家安全局刚刚在这里学到了宝贵的一课，并且正在制定政策以确保需要两个人在场才能访问私人数据).正确记录和记录访问尝试也很重要.

5 (Leaks) If the data is encrypted onsite, and the admins/employees/janitors do not have the keys to decrypt the data, then leaking the information is of limited value (especially if #4 is handled correctly). You can also place limitations on who and how the data can be accessed (the NSA just learned a valuable lesson here and are enacting policies to ensure that two people need to be present to access private data). Proper journaling and logging of access attempts is also important.

6(社会工程) 攻击者将尝试致电您的支持台，冒充客户，并请求访问特权信息或让支持台更改信息(密码、个人信息等).他们通常会将多个支持呼叫链接在一起，直到拥有控制帐户所需的所有信息.支持人员需要接受培训，并限制他们将提供哪些信息，以及他们可以编辑哪些数据.

6 (Social Engineering) Attackers will attempt to call your support desk, impersonate a client, and either request access to privileged information or have the support desk change information (password, personal information, etc). They will often chain together multiple support calls until the have all the information needed to take control of an account. Support needs to be trained and limited in what information they will give out, as well as what data they can edit.

7(中间人) 这是攻击者试图将自己注入通信流的地方，最常见的方法是使用在客户端机器上运行的 rootkit 或虚假访问积分(例如wifi).基于有线/协议的加密(例如 SSL)显然是第一级保护.但是变种(例如浏览器中的人)不会受到缓解，因为它们会在 SSL 数据包被解密后看到数据.一般来说，客户端是不可信的，因为平台本身是不安全的.鼓励用户使用专用/隔离的机器是一种很好的做法.限制密钥和解密数据存储在内存或其他可访问位置的时间.

7 (Man-in-the-middle) This is where an attacker will attempt to inject himself into the flow of communication, most commonly through the use of rootkits running on client's machines or fake access points (wifi, for example). Wire/protocol based encryption (such as SSL) obviously is the first level of protection. But variants (such as man-in-the-browser) won't be mitigated as they will see the data after the SSL packets have been decrypted. In general, clients cannot be trusted, because the platforms themselves are insecure. Encouraging users to use dedicated/isolated machines is a good practice. Limit the amount of time that keys and decrypted data are stored in memory or other accessible locations.

8-9(CSRF 和重放) 与中间人类似，这些攻击将尝试复制(例如捕获)用户的凭据和/或交易并重复使用它们.针对客户端来源的身份验证、限制凭据有效时的窗口、要求验证交易(通过电子邮件、电话、短信等单独渠道)都有助于减少这些攻击.

8-9 (CSRF and Replay) Similar to man-in-the-middle, these attacks will attempt to duplicate (e.g. capture) a user's credentials, and/or transactions and reuse them. Authentication against the client origin, limiting the window when credentials are valid, requiring validation of the transaction (via a separate channel such as email, phone, SMS, etc) all help to reduce these attacks.

正确的加密/散列/加盐可能是公司搞砸的第一件事.假设你所有的其他防御都失败了(就像你说的，他们可能会)，这是你最后的希望.在这里投资并确保正确完成.确保各个用户记录使用不同的密钥(而不是一个主密钥)进行编码.让客户端进行加密/解密可以解决很多安全问题，因为服务器永远不知道密钥(因此没有人可以窃取它们).另一方面，如果客户端丢失了密钥，那么他们也会丢失他们的数据.因此，必须在那里进行权衡.

Proper encryption/hashing/salting is probably the first thing that companies screw up. Assuming all your other defense fall (and like you said, they probably will), this is your last hope. Invest here and ensure that this is done properly. Ensure that individual user records are encoded with different keys (not one master key). Having the client do the encryption/decryption can solve a lot of security issues as the server never knows the keys (so nobody can steal them). On the other hand, if the client looses the keys, then they will loose their data as well. So a trade off will have to be made there.

投资于测试/攻击您的解决方案.实施网站/数据库的工程师通常无法考虑所有可能的攻击场景.

Invest in testing/attacking your solution. The engineer that implements a website/database is often not equipped to think about all the possible attack scenarios.

这篇关于保护 Web 服务器数据的最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！