目录
1前言 (2)
2跨站点脚本防范(XSS) (2)
3防SQL注入规范 (3)
4基本开发安全规范 (3)
4.1页面组件安全防范 (3)
4.2敏感数据的安全防范 (5)
4.3Java安全防范 (6)
5应用集成安全规范 (7)
1前言
为了提高我们的应用安全质量，提高安全的规范性，我们特制定本规范。规范中的条目分为3类，含义分别如下：
Policy：必须遵循的策略，实现方法可以自己考虑，但不能违反策略的规定
Discipline：必须遵守的纪律，必须按照规定中的描述实施，绝对不能违反
Guideline：建议性的指南和规范，将逐步要求大家遵循实施
2跨站点脚本防范(XSS)
XSS的类型：DOM-based XSS、Reflected XSS、Persistent XSS。
Policy 2-1: 跨站点脚本防范的基本原则：
一切的输入/输出都是有害的，不要信任任何输入/输出数据。
所有传递过程都不能保障无侵入，执行前、存储前、显示前都要进行“数据清洁“。 所有的数据校验、处理工作尽量在服务器端进行。
Discipline 2-1: DOM-based XSS的防范
当操作页面中DOM对象的时候，要对其输入的参数进行处理，防止XSS的注入。可采用escape、encodeURI、encodeURIComponent或自定义方法进行处理。示例：Window.location=encodeURI(”http:
//www.baidu/login?page=1”);
Discipline 2-2: 设置输入/输出字符校验的白名单/黑名单，只认为在白名单之内/在黑名单之外的字符才是合法。可以使用正则表达式对%?<>{};&+=-"/\'#&|@等特殊符号进行过滤。
Discipline 2-3: 对输入/输出进行Encode，将输入/输出进行转义成HTML实体编码(ISO 8859-1 Latin1)或其他编码，使得其在浏览器中不可自动执行。
3防SQL注入规范
Policy 3-1：防SQL注入基本原则：
所有用户输入都比进行合法性校验。
所有数据库SQL操作必须参数化。
Policy 3-2: 数据库Schema分离，从设计角度上最大程度减少SQL注入造成危害
Guideline 3-3: 尽量使用PreparedStatement代替Statement，一方面，在大多数情况下，使用PreparedStatement的性能将优于使用Statement，另外一方面，可以最大限度的减少SQL注入发生的可能行。
Guideline 3-4: 用户提交的数据都应该做合法性校验，避免用户输入‘，““，-，%，#,&,|，@，+等有可能导致SQL注入的危险字符给系统造成危害。
4基本开发安全规范
4.1页面组件安全防范
Discipline 4-1-1: 页面标签必须关闭，属性值必须加引号。
在页面中使用的标签不关闭，属性值不加引号往往成为被攻击点，攻击者很容易的利用这些漏洞进行注入。避免这些漏洞的出现可以提高被攻击的可能。
Discipline 4-1-2: Form提交方式必须选用POST。
Form默认的提交方式是Get，这种方式将表单中数据的按照variable=value的形式，使用“?”添加至Action所指向的URL后面，各个变量之间使用“&”连接。所要传递的
信息量除受URL长度限制之外，信息内容都显示暴露。
在使用Form的时候必须将提交方式置为POST。示例：
<form action="…" method="post" target="_blank">
…
</form>
Discipline 4-1-3: 所有的非ASCII字符在URL中传递时都需要按照协商好的编码方式做URL编码。
推荐使用encodeURI、encodeURIComponent或者自定义encode实现。
encodeURI、encodeURIComponent默认都返回UTF8编码的URL，区别在于encodeURI方法不会对下列字符进行编码: ":"、"/"、";" 和"?"。而encodeURIComponent 则会对这些字符进行编码处理。
Discipline 4-1-4: 尽量使用对象的innerText，不要使用innerHtml属性。
对象的innerText属性默认会对输入的数据进行encode，使得如果数据的数据还有html可执行标记时不会直接执行，而如果使用innerHtml属性的话不会保障。
<SPAN id=”Addr”></SPAN>
<Script>
// Using innerText renders the content safe.
Addr.innerText=”…”;
//Using innerHtml requires the use of HtmlEncode to make it safe.
Addr.innerHtml=””;
</Script>
Guideline 4-1-5: 输入框设置最大长度、输入数据类型限制。
输入框一般是攻击者比较钟意的攻击对象，攻击者可以通过输入框限制不足的弱点进行数据窃取(比如SQL注入)、或者制造迫害(如比XSS)。我们可以通过对输入框最大长度、输入数据类型的限制，从一定程度上防范这样的攻击。
我们可以根据实际需求，对一些输入框限定只允许输入字母、数字等。同时对输入的数据长度做限制。
Guideline 4-1-6: 关闭客户端自动完成功能，减少驻留在客户端数据。
<FORM … AUTOCOMPLETE=”OFF”/>
<INPUT … AUTOCOMPLETE=”OFF”/>
Guideline 4-1-7: 设置<Frame>/<iFrame>受限，防止脚本执行。
将<Frame>/<iFrame>中security属性设置为restricted后，Frame中的脚本将不
iframe参数传递能执行(仅限于IE)。示例：
Guideline 4-1-8: 设置URL、图片等资源访问的白名单。
4.2敏感数据的安全防范
Policy 4-2-1：不能任意在Cookie、Session、ServletContext中存放数据，对于这些对象中存放的数据，必须有统一定义、说明、Lifecycle的管理等。
Policy 4-2-2: 对于敏感信息都必须保障其私密性。
在页面显示、操作交互中不可避免的会有一些如用户的标识信息、密码、帐号信息、涉及的金额信息等敏感数据(保密性的数据)的存在。为保障这些数据不被曝露而提高安全性，我们要做到所有敏感信息必须进行加密处理，不能以明文的形式存在于任何网络、内存及其它持久化介质中(如：数据库、文件磁盘系统等)。
Discipline 4-2-3: 所有的密码、key、帐号等机密信息都不能在URL中传递。
Discipline 4-2-4: 所有的密码、key、银行账号等机密信息都不能存储到Cookie，Session、ServletContext中。
Discipline 4-2-5: 防止信息泄漏
在系统上线使用的log level对应的日志输出中不允许包含任何密码、key、账号等机密信息。
SNV集成分支上的代码中不允许存留可用的system.out/err.print语句。
在测试/调试阶段所使用的测试页面、单元测试模块等不允许提交到SVN集成分支上。 不允许将系统产生的错误异常信息直接显示给用户，需要有统一的错误处理。
Guideline 4-2-6: 尽量减少不必要的信息传递。
在信息的传递过程中，如果当前Step中的对象、对象的属性、参数等在下一个Step 中不需要，则不要再做传递，甚至可以显式的销毁。这样可以有效的减少信息被截获的机率，特别是敏感数据(例如用户密码、账户信息等等)。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。