任务详情
在软件开发和系统架构设计中，安全设计原则是一组指导方针，旨在帮助开发者和设计师构建更安全的系统。这些原则可以减少系统的脆弱性，提高对抗潜在威胁的能力。 通过各种资料，尽可能多的搜集安全原则。 1. 给出所有你能找到的安全原则的名称，内容和来源信息（图书名称，网站链接，...）。 2. 根据2/8原则，选择你认为最重要的20%，给出应用实例（代码编写，命令行应用等），写出实践过程
学习内容
原则1：最小化攻击面：
系统每增加一个功能特性就有可能会引入新的风险，通过安全开发可以减少攻击面进而达到控制系统整体风险的目的。
打个比方说，某在线web应用向用户提供了一个通过搜索来获取帮助的功能，如果后端代码没有正确实现该功能就有可能导致存在SQL注入漏洞，但是即便如此，我们还是有办法降低或消除风险的，比如：
u 该帮助功能只能被授权的用户使用。
u 后端代码对用户输入的数据进行了校验。
u 帮助功能不支持搜索，只支持查看。
可以看到，以上的第一、二点收缩了攻击面，即增加了攻击条件，减少了可以攻击的人数，而第三点则完全避免了风险，即攻击面完全消除了。其中第三点符合“简化系统设计”的原则，即不增加不必要的功能模块和特性。
另外一个典型的例子是：统一登录认证，所有业务都在认证中心登录，避免反复登录，这样的可以防止同样的安全问题在不同的业务上发生，相当于将攻击从面收缩到一个点上，我们只要把这个点做得足够安全即可。
原则2：Secure default：
在软件领域的含义就是：让默认的配置和策略尽可能的安全。比如，在许多场合，安全和产品体验经常会发生冲突，这时候应当选择安全优先，在安全的前提下，可以允许通过手动关闭安全配置或策略来提升产品体验。
比如，产品应该默认打开密码复杂度策略，即不允许用户使用不符合密码复杂度策略的密码，但产品可能可以允许用户关闭这个策略来提升体验。
注：只有充分了解业务安全需求的前提下，才能更好的使用该原则。
原则3：权限最小化：
事物只拥有可以完成他们任务的最小权限，即不赋予不必要的权限。包括但不限于：用户权限和资源权限（比如可以使用的CPU、内存、网络流量和存储容量等等）。
比如，某中间件服务器只需要访问网络、读取数据库和向日志服务器写日志的权限，那就完全没有必要赋予其更多其它的权限（特别是管理级别的特权）。
原则4：纵深防御：
从不同的维度去实施安全保护措施来缓解被攻击的风险。实施纵深防御策略，可以让攻击变得更加难以实施，漏洞变得更加难以利用。
比如，为了防止或减少SQL注入带来的危害，我们可以：
u 在应用外围部署WAF。
u 应用对输入数据进行有效性验证或进行参数化查询。
u 数据库连接账户隔离以及权限最小化。
u 敏感数据加密存储。
u 对数据库进行安全配置或关闭不必要的强大功能。
但是，该原则和原则9—“简化系统设计”在一定程度上是相违背的，即当纵深防御机制设计得过于复杂时，同时也增加了系统的复杂性，导致为了解决某些安全问题而引入了其它的安全问题。比如：设计登录认证时，要求用户必须设置过于复杂的口令，由于用户无法难以记住，可能会将其写在纸条贴在桌面上。
因此，本原则也必须结合业务和实际情况进行分析，综合平衡两者矛盾。
原则5：Fail securely：
即业务系统能够正确安全地处理各种异常和错误。
原则6：不要信任第三方系统
不少产品需要和第三方的业务系统对接，并使用其提供的数据，但是一般情况下，我们是无法掌控这些第三方系统的安全设计和开发过程的，所以它们也可能会存在安全漏洞，进而被人攻击，因此，我们必须充分考虑到当第三方系统被攻击时，如何保障自己的业务系统的安全性。
比如：当我们向第三方系统查询数据时，必须对数据进行有效性验证后才可以使用（比如使用这些数据进行数据库查询或显示到用户浏览器上）。
原则7：业务隔离：
基本思想是将业务系统尽分成尽可能多的独立单元，但某个单元出现安全缺陷时，可以将损害程度降到最低，通俗地说，就是不要把所有鸡蛋都放在一个篮子里。
比如：将具有核心数据的业务和BBS部署在同一个服务器上，很多BBS站点都使用开源系统（比如 discuz）搭建，经常爆出各种漏洞，一旦BBS被攻陷，将会威胁到核心业务数据的安全性。
注：隔离可以是系统内部功能模块之间的（比如：web服务器和数据库服务器等），也可以业务部署层面之间的（比如：BBS和核心业务）。
原则8：公开设计：
有些人认为，只要产品内部的实现细节不被外人知道，那么产品就是安全的，但其实这是一种保护效果比较差的方法。当然，并不是说这样做毫无意义，也的确增加了攻击的难度，但是不能对其形成过多依赖，甚至把它当成主要或唯一的安全防护手段。
比如：不少公司都实现了自己的私有加密算法，他们认为只要算法不被泄露或公开，那么算法就是安全的，但实际面临以下问题：
u 攻击者可以通过抓包或逆向二进制来进行破解。
u 攻击者通过入侵服务器或给员工机器种植木马的方式来获取到源代码。
u 对公司不满的员工故意公开算法。
一旦以上任意条件满足时，则这种不公开设计方式的保护也就变得没有意义，因此，正确地做法应该是：假设算法被破解或完全公开，同样能保证系统的安全。典型的案例诸如业界广泛使用的对称加密算法（AES）和非对称加密算法（RSA），它们的设计实现都是公开的，但是仍然是安全的。
原则9：简化系统设计
“最小化攻击面”和“简化系统设计”原则是相辅相成的，由于复杂的系统设计会导致攻击面变宽，所以如果存在多种系统设计方案，则应尽量选择最简单的那种方案。
原则10：使用白名单
白名单的思想为：除了定义为合法的，其它都拒绝。与之相反的黑名单思想为：除了定义为不合法的，其它都允许。使用白名单的好处是它有可能能够防御各种未发现的安全隐患，而这是黑名单所做不到的。
比如：对所有输入数据进行过滤时，适合使用白名单原则，未在白名单范围内的数据将被视为非法，相反地，如果使用黑名单，其规则可能会被预想不到的方法绕过。
原则11：失败保险默认原则
该原则指的是系统的设计、实现和运营应该是透明和公开的，使得外界可以了解系统的工作原理和内部机制。这样做有以下优点：
透明度：公开设计原则确保系统的开放性，让用户和其他相关人员能够了解系统的运作方式和特性。
可信度：公开设计有助于提高用户对系统的信任度，用户可以更加信任系统的安全性和有效性。
质量改进：由于其他人可以查看和审查系统的设计，可能会有更多的人提供反馈和建议，从而促进系统的质量改进。
创新和发展：公开设计可以激发创新和竞争，鼓励开发者提供更好的解决方案和技术进步。
然而，公开设计原则也存在一些潜在的弊端：
弊：
安全风险：公开设计可能使得系统的漏洞和弱点更容易被攻击者找到，从而增加了系统的安全风险。
商业机密：有些公司可能拥有自己的核心技术和商业机密，公开设计原则可能会泄露这些信息，对公司的竞争优势造成损害。
维护成本：公开设计需要投入更多的资源来编写文档、提供支持和回答问题，这可能增加系统的维护成本。
要衡量遵守公开设计原则对系统安全性的影响，可以考虑以下因素：
平衡：需要在透明度和安全性之间取得平衡，确保系统的内部机制不会被滥用，同时确保系统的安全性得到保证。
密码学安全：对于涉及密码学等敏感信息的系统，公开设计可能会增加安全风险，因此需要谨慎考虑。
内部审查：通过内部的安全审计和审查，确保公开的设计不泄露重要的安全信息。
安全培训：对开发人员和运营人员进行安全培训，以确保他们能够正确理解和遵守公开设计原则，并使用最佳的安全实践。
总的来说，遵守公开设计原则可以提高系统的透明度和可信度，但也需要注意安全性和保护商业机密的问题。在系统设计过程中，需要综合考虑各种因素，以确保整体的系统安全性。
如果不需要操作系统的配合，实现一个给文件加密的应用程序会遇到一些困难。以下是一些可能的困难：
硬件访问：在没有操作系统支持的情况下，应用程序将无法直接访问计算机的硬件资源，包括硬件加密解密功能。应用程序通常依赖操作系统提供的接口和驱动程序来使用硬件功能。
文件系统访问：文件加密应用程序需要访问和操作硬盘或其他存储设备上的文件。在没有操作系统的支持下，应用程序无法直接访问文件系统，需要自行实现文件系统访问功能。
权限管理：操作系统通常提供权限和身份验证机制来确保文件只能被授权的用户或应用程序访问。在无操作系统支持的情况下，应用程序需要自行实现权限管理机制，这将增加复杂性和安全风险。
用户界面：操作系统通常提供用户界面来与应用程序交互，包括输入密码或选择加密算法等。没有操作系统的支持，应用程序需要自己实现用户界面功能。
资源管理：操作系统负责管理系统资源，如内存和处理器时间。在没有操作系统支持的情况下，应用程序需要自行管理资源，例如内存分配和线程调度，这会增加复杂性和开发难度。
总体来说，没有操作系统的支持，实现一个给文件加密的应用程序将需要自行处理硬件访问、文件系统访问、权限管理、用户界面和资源管理等一系列复杂的任务。这将增加开发难度，并且可能导致性能和安全性问题。因此，通常情况下，借助操作系统提供的功能和接口来实现文件加密应用程序是更可行和高效的选
原则12：完全仲裁原则
授权检查覆盖任何一个访问操作
安全机制又能力标识每一个访问操作请求的所有源头
能够对待为了提高性能而缓存的检查结果
原则13：经济性原则（Economy of Mechanism）
安全机制设计尽可能简单短小，从而在排查缺陷、检测漏洞时代码更容易处理
原则15：默认拒绝原则（Fail-Safe Defaults）
只要没有授权的信息就不允许访问
不能出现本该允许的请求被拒绝与本该拒绝的请求被允许
原则16：开放设计原则（Open Design）
不将安全机制的设计作为秘密，不将系统安全性寄托在保守安全机制设计秘密的基础上
应在隔开安全机制设计方案的前提下，借助容易保护的特定元素，如密钥、口令等来增强系统的安全性
开放设计有助于安全机制接受广泛的审查
原则17：特权分离原则（Separation of Privilege）
细分特权，分配给多个主体，减少每个特权拥有者的权利
原则18：最少公共机制原则（Least Common Mechanism）
将多个用户公用或被全体用户依赖的机制数量降到最少
原则19：心理可接受原则（Psychological Acceptability）
安全机制的良好交互性、安全机制、安全目标的吻合性
资料来源：产品安全设计十大原则_最小攻击面设计原则-CSDN博客
2020-2021-1学期 20202406 《网络空间安全专业导论》第十一周学习总结 - 20202406-郭子钰 - 博客园 (cnblogs.com)
三、实践过程
白名单策略
任何时候，尽可能使用白名单策略
if (Pattern.matches("^[0 -9A -Za -z_]+$", name)){ throw new IllegalArgumentException("Invalid name"); }
这样的代码确保 name参数只包含字母、以及下划线
这样就可以确保我们只让这部分合法的用户进入我们的网站，将不合格的用户全部剔除了，防止输入安全问题的出现
白名单编写
以pikachu靶场SSRF(file_get_content)为例
添加白名单前，可以访问info2.php
也可以访问本地文件hosts文件
?file=../../../../../../../../windows/system32/drivers/etc/hosts
添加白名单
echo $filename."<br >";
$octet = explode(".",$filename);
echo $octet[1]."<br \>";
if($octet[1]!="php"){
die("黑客!!!");
}
此函数返回由字符串组成的数组，每个元素都是 string 的一个子串，它们被字符串 separator 作为边界点分割出来。
写入白名单后
白名单+xml库
private void createXMLStream(BufferedOutputStreamoutStream, User user) throws IOException{ // Write XML string if userID contains alphanumeric and underscore characters only if (!Pattern.matches("[_a-bA-B0-9]+", user.getUserId())){ // Handle format violation } if (!Pattern.matches("[_a-bA-B0-9]+", user.getDescription())){ // Handle format violation } String xmlString= "<user><id>"+ user.getUserId()+ "</id><role>operator</role><description>"+ user.getDescription() + "</description></user>"; outStream.write(xmlString.getBytes()); outStream.flush(); } public static void buidlXML(FileWriterwriter, User user) throwsIOException{ Document userDoc= DocumentHelper.createDocumen(); Element userElem= userDoc.addElement("user"); Element idElem= userElem.addElement("id"); idElem.setText(user.getUserId()); Element roleElem= userElem.addElement("role"); roleElem.setText("operator"); Element descrElem=userElem.addElement("description"); descrElem.setText(user.getDescription()); XMLWriter output = null; try{ OutputFormat format = OutputFormat.createPrettyPrint(); format.setEncoding("UTF-8"); output = new XMLWriter(writer, format); output.write(userDoc); output.flush(); } }
以上这段代码使用白名单的策略确保了一个安全的xml库，防止恶意用户输入不合法的输入从而攻击我们的库。
黑名单策略
public String removeJavascript(String input){ Pattern p = Pattern.compile("javascript", Pattern.CASE_INSENSITIVE ); Matcher m = p.matcher(input); return (! m.matches()) ? input : ""; }
这段代表可以将指定的输入列入黑名单，拒绝了我们想要拒绝的目标。
