2. 坚持最小权限,把可能造成的危害降到最低。
3. 默认不信赖,采取白名单机制,只放行已知的操作。
4. 永久不要相信用户的输入,对所有输入进行前台和后台两次检讨。
2 常见WEB潜在问题
输入验证:嵌入到查询字符串、表单字段、cookie 和 HTTP 头中的恶意字符串的攻击。这些攻击包括命令实行、跨站点脚本(XSS)、SQL 注入和缓冲区溢出攻击。身份验证:标识欺骗、密码破解、特权提升和未经授权的访问。授权验证:访问保密数据或受限数据、修改数据以及实行未经授权的操作。配置管理:对管理界面进行未经授权的访问、具有更新配置数据的能力以及对用户帐户和帐户配置文件进行未经授权的访问。敏感数据:透露保密信息以及修改数据。会话管理:捕捉会话标识符,从而导致会话挟制及标识欺骗。加密管理:访问保密数据或帐户凭据,或二者均能访问。参数操作:路径遍历攻击、命令实行以及绕过访问掌握机制,从而导致信息泄露、特权提升和谢绝做事。非常管理:谢绝做事和敏感的系统级详细信息的泄露。审核和记录:不能创造入侵迹象、不能验证用户操作,以及在诊断时涌现困难。
3 基本开拓安全规范3.1 跨站点脚本(XSS)戒备XSS的类型:反射型XSS、存储型XSS、DOM型XSS。
跨站点脚本戒备的基本原则:
1. 统统的输入/输出都是有害的,不要信赖任何输入/输出数据。
2. 所有通报过程都不能保障无侵入,实行前、存储前、显示前都要进行"数据洗濯"。
3. 所有的数据校验、处理事情要在前端和做事器端两次进行。
4. 目前所有的XSS通过com.keegoo.core.util.XSSUtil来过滤。
DOM-based XSS的戒备当操作页面中DOM工具的时候,要对其输入的参数进行处理,防止XSS的注入。可采取escape、encodeURI、encodeURIComponent或自定义方法进行处理。示例:
Window.location=encodeURI("http://www.dhgate.com");
对输入/输出进行Encode 将输入/输出进行转义成HTML实体编码(ISO 8859-1 Latin1)或其他编码,使得其在浏览器中不可自动实行。
不要在html元素和属性中利用未经转义的不屈安内容。
3.2 防SQL注入规范1. 防SQL注入基本原则:所有用户输入都必须进行合法性校验。所有数据库SQL操作必须参数化。
2. 回收开拓职员等操作生产库权限:减少开拓职员、非DBA操作生产库的权限;数据库数据查询要有权限分级和审核。
3. 只管即便利用PreparedStatement代替Statement,一方面,在大多数情形下,利用PreparedStatement的性能将优于利用Statement,其余一方面,可以最大限度的减少SQL注入发生的可能行。
4. 用户提交的数据都该当做合法性校验,避免用户输入',"",-,%,#,&,|,@,+等有可能导致SQL注入的危险字符给系统造成危害。
3.3 页面组件安全戒备1. 页面标签必须关闭,属性值必须加引号。在页面中利用的标签不关闭,属性值不加引号每每成为被攻击点,攻击者很随意马虎的利用这些漏洞进行注入。避免这些漏洞的涌现可以提高被攻击的可能。
2. Form提交办法必须选用POST。Form默认的提交办法是Get,这种办法将表单中数据的按照variable=value的形式,利用"?"添加至Action所指向的URL后面,各个变量之间利用"&"连接。所要通报的信息量除受URL长度限定之外,信息内容都显示暴露。
在利用Form的时候必须将提交办法置为POST。示例:
<form action="…" method="post" target="_blank">…</form>
3. 所有的非ASCII字符在URL中通报时都须要按照协商好的编码办法做URL编码。推举利用encodeURI、encodeURIComponent或者自定义encode实现。encodeURI、encodeURIComponent默认都返回UTF8编码的URL,差异在于encodeURI方法不会对下列字符进行编码: ":"、"/"、";" 和 "?"。而encodeURIComponent则会对这些字符进行编码处理。
4. 只管即便利用工具的innerText,不要利用innerHtml属性。工具的innerText属性默认会对输入的数据进行encode,使得如果数据的数据还有html可实行标记时不会直接实行,而如果利用innerHtml属性的话不会保障。
5. 输入框设置最大长度、输入数据类型限定。输入框一样平常是攻击者比较钟意的攻击工具,攻击者可以通过输入框限定不敷的弱点进行数据盗取(比如SQL注入)、或者制造伤害(如比XSS)。我们可以通过对输入框最大长度、输入数据类型的限定,从一定程度上戒备这样的攻击。我们可以根据实际需求,对一些输入框限定只许可输入字母、数字等。同时对输入的数据长度做限定。
6. 关闭客户端自动完成功能,减少驻留在客户端数据。
7. 设置<Frame>/<iFrame>受限,防止脚本实行。将<Frame>/<iFrame>中security属性设置为restricted后, Frame中的脚本将不能实行(仅限于IE)。
3.4 敏感数据的安全戒备
1. 不能任意在Cookie、Session、ServletContext中存放数据,对付这些工具中存放的数据,必须有统一定义、解释、Lifecycle的管理等。
2. 对付敏感信息都必须保障其私密性。在页面显示、操作交互中不可避免的会有一些如用户的标识信息、密码、帐号信息、涉及的金额信息等敏感数据(保密性的数据)的存在。为保障这些数据不被曝露而提高安全性,我们要做到所有敏感信息必须进行加密处理,不能以明文的形式存在于任何网络、内存及其它持久化介质中(如:数据库、文件磁盘系统等)。
3. 所有的密码、key、帐号等机密信息都不能在URL中通报。
4. 所有的密码、key、银行账号等机密信息都不能存储到Cookie,Session、ServletContext中。
5. 防止信息泄露:
1. 在系统上线利用的log level对应的日志输出中不许可包含任何密码、key、账号等机密信息。
2. SVN集身分支上的代码中不许可存留可用的system.out/err.print语句。
3. 在测试/调试阶段所利用的测试页面、单元测试模块等不许可提交到SVN集身分支上。
4. 不许可将系统产生的缺点非常信息直接显示给用户,须要有统一的缺点处理。
6. 只管即便减少不必要的信息通报。在信息的通报过程中,如果当前Step中的工具、工具的属性、参数等不才一个Step中不须要,则不要再做通报,乃至可以显式的销毁。这样可以有效的减少信息被截获的机率,特殊是敏感数据(例如用户密码、账户信息等等)。
3.5 WEB安全戒备
1. Cookie的安全戒备:
(1)存储于cookie中的敏感数据必须加密。
(2)没有分外哀求下,只管即便利用会话cookie(非持久化)。
(3)如果利用持久化cookie该当设置cookie超时。
(4)激活cookie安全传输,表示创建的 cookie 只能在https连接中被浏览器通报到做事器端进行会话验证,如果是http连接则不会通报该信息。
2. 必须设置session的超时时间。web.xml中配置示例:
<session-config>
<session-timeout>10</session-timeout>
</session-config>
3. 必须构建统一的缺点处理页面。web.xml示例:
<error-page>
<error-code>500</error-code>
<location>/error.jsp</location>
</error-page>
4. 多线程中线程安全的戒备:
1. 只管即便少用静态(static)变量和static方法。(除了静态常量:static final constants)。
2. 只管即便多线程框架(java.util.concurrent)构建多线程同步机制。
3. 利用ThreadLocal避免多个线程之间类成员的共享冲突。
4. 如非必要,不要利用synchronized关键字。必须要利用synchronized时,应将同步范围最小化,即将同步浸染到最须要的地方,避免大块的同步块或方法等。
5. 增加Referer的检讨,防止造孽访问。Referer是HTTP Header中的一个字段,当浏览器想做事器发送要求时,Referer用来关照做事器要求发起的位置。
2、 编码规范
1. 排版规范
1.1 规则
1.1.1 代码块要采取缩进风格编写,缩进长度为4个空格,如果利用tab缩进请在IDE中将tab设置为4个空格。利用默认的tap缩进会导致代码在其他编辑器中不对齐。
1.1.2 大括号利用约定:如果大括号内为空,则写成{}即可;如果非空代码块则:
1. 左大括号前不换行
2. 左大括号后换行
3. 右大括号前换行
4. 右大括号后还有else等代码则不须要换行;表示终止的右大括号后必须换行。
正例:
1.1.3 左小括号与字符之间不涌现空格,同样,右小括号与字符之间也不涌现空格。
反例:if(空格a == b空格)
1.1.4 单行字符数不超过80个,超出须要换行
1. 换行要在低优先级操作符出划分新行,操作符与下行一起换行。
2. 第二行相对第一行缩进4个空格,从第三行开始不再缩进。
3. 方法调用时多个参数须要换行的话,在逗号后换行。
4. 不要在逗号前换行。
1.1.5 不许可把多个短句写在同一行中,即一行一句代码。
反例:String cplx; String cpmc;
1.1.6 If,for,do,while等语句的实行语句不论多少行都要加{}。
反例:if(a == b) String c=b;
1.1.7 两个以上的变量,关键字,常量进行对等操作时,他们之间的操作符前后加空格,进行非对等操作时,如果是关系密切的立即操作符(如.),后不应加空格。由于留空格产生的清晰性是相对的,以是在已经非常清晰的语句中没有必要加空格,如果语句已足够清晰则括号的内侧(即左括号后面和右括号前面)不须要加空格,多重括号间不必加空格,由于在java中括号已经是最清晰的标志了。
示例:
1. 逗号,分号只在后面加空格
2. 比较操作符,赋值操作符"="、"+=",算术操作符"+"、"%",逻辑操作符"&&"、"&",位域操作符"<<","^"等双目操作符前后加空格。
3."!","~","++","--","&"等单目操作符前后不加空格
1.1.8 方法参数在定义和传入时,多个参数逗号后面必须加空格。
1.2 建议
1.2.1 类属性和类方法的定义不要交叉放置,同一类东西放在一起
格式:
2. 注释规范
2.1 类,类属性, 类方法的注释必须利用javadoc规范,即/ 内容/格式,不得利用// xxxx的办法。
解释:javadoc办法在eclipse中调用方法时会提示干系的注释,不进人方法即可悬浮提示参数,返回值的意义等,提高阅读效率。
2.2 所有的抽象方法(包括接口中的方法)必须利用javadoc注释,除了返回值、参数、非常解释外,还必须指出该方法做什么事,实现什么功能。
2.3 所有类必须注释创建者,创建韶光。
2.4 方法内部单行注释,在被注释代码上面另起一行,利用//注释;方法内部多行注释利用/ /;把稳与代码对齐。
2.5 所有的列举类型字段必须要有注释,解释每一项的用场。
2.6 代码修正的同时,注释也要修正,尤其是参数,返回值 ,核心逻辑等。
2.7 如果要注释代码,请在上面详细解释;如果是无用的代码,请删掉,不要注释掉。
2.8 注释的哀求:第一、能准确的反应设计思想和代码逻辑;第二、能够描述业务含义,是别的程序员能够迅速理解该段代码的意义,不要怕字多,不是说只要自己能看懂就行,必须担保其余一个人拿到你这段代码看了注释就知道你在干什么。
2.9 注释也不是越多越好,该当力求精简准确、表达到位;过多过滥的注释,一旦代码逻辑修正,那么修正注释将是一个不小的包袱。
如:setCpmc(cpmc),方法名setCpmc加上一个故意义的变量名cpmc,已经解释了这是在什么,语义清晰的代码不须要额外的注释。
2.10 分外注释标记,请注明标记人,标记韶光,估量处理韶光。把稳及时处理。
1. 待办事项(TODO):表示须要实现,但是目前还没有实现的功能。
2. 缺点,不能事情(FIXME): 表示代码是缺点的,不能事情,须要及时的纠正。
2.11 顺序实现流程的解释利用1、2、3、4在每个实现步骤部分的代码前面进行注释。
2.12 避免在注释中利用缩写单词。
3. 命名规范
3.1 类名利用UpperCamelCase风格,屈服驼峰形式,在哪个包下就以那个包的名字做后缀。
正例:action层的类CpglAction
反例:cpglAction
3.2 方法名、参数名、成员变量、局部变量都统一利用 lowerCamelCase 风格,必须屈服 驼峰形式。
正例:getUserMessage();
3.3 常量名全部大写,单词间用下划线隔开,力求语义表达完全清楚,不要嫌名字长。
正例:MAX_STOCK_COUNT
反例:MAX_COUNT
3.4 中括号的数组类型的一部分,数组定义如下:String[] args;
反例:String args[];
3.5 包名统一利用小写,点分隔符之间有且仅有一个自然语义的英语单词或中文首字母。包名统一利用单数形式,但是类名可以利用复数形式。
正例:运用工具类包名为com.ddkj.util、类名为 MessageUtils
3.6 杜绝完备不规范的缩写,避免望文不知义。
反例:AbstractClass"缩写"命名成 AbsClass;condition"缩写"命名成 condi,此类随 意缩写严重降落了代码的可阅读性。
3.7 为了达到代码自阐明的目标,任何自定义编程元素在命名时,利用只管即便完全的单词 组合来表达其意。
反例:int name;
3.8 Service/DAO 层方法命名规约:
1. 获取工具的方法用get做前缀
2. 获取多个工具的方法用get做前缀,List做后缀
3. 获取分页工具的方法用get做前缀,Page做后缀
4. 获取统计值的方法用count做前缀
5. 插入方法用save/insert做前缀
6. 删除方法用remove/delete做前缀
7. 更新方法用update做前缀
4. 编码规范
4.1 一个函数仅完成一件功能,纵然大略的功能也该当编写方法实现。
4.2 明确类的功能,精确地实现类的设计。一个类仅实现一组附近的功能。划分类的时候,该当只管即便把逻辑处理、数据和显示分离,实现类功能的单一性。
4.3 自己抛出的非常必须填写详细的描述信息。
示例:
4.4 把稳运算符的优先级,用括号明确表达式的操作顺序,不要利用默认优先级。避免不必要的误解。
示例:下面的表达式
如果写成
虽然不会报错,但是语句不易理解,造成判断条件出错。
4.5 避免利用不易理解的数字,用故意义的标识来代替。例如含有物理意义的常量可以用静态变量代替。
4.6 只管即便不要利用难懂的技巧性很高的语句,除非必须要用的时候。
4.7 凑集中的数据如果不该用了该当及时开释,尤其是可重复利用的凑集。由于凑集保存了工具的句柄,垃圾网络器不会回收。
5. 非常处理
5.1 runtimeException可以通过预先检讨进行规避,不应该通过catch来处理,比如:IndexOutOfBoundsException,NullPointException等等。无法通过预先检讨的非常除外,比如要解析一个外部传过来的字符串类型的数字,可以通过捕获NumberFormatException来实现。
5.2 捕获非常后须要对非常进行处理,如果不想处理请将它抛给它的调用者,最外层利用者必须处理非常,将其转化为用户可以理解的内容。
5.3 Finally块必须对资源工具,流工具进行关闭,有非常也要try-catch。
5.4 不能在finally块中利用return,由于finally中的return实行后将不再实行try中的return。
5.5 捕获非常和抛非常必须是完备匹配的,比如一个方法抛出一个NumberFormatException,那么调用它时捕获的非常类型必须是NumberFormatException。
5.6 调用方法须要进行null判断,防止NullPointException。
级联调用obj.getA().getB().getC()易产生NullPointException。
3、 数据库规范
1、数据库命名规范采取26个英笔墨母(区分大小写)和0-9的自然数(常常不须要)加高下划线'_'组成,命名简洁明确,多个单词用下划线'_'分隔,一个项目一个数据库
2、数据库表命名规范2.1数据表命名规范
(1)采取26个英笔墨母(区分大小写)和0-9的自然数(常常不须要)加高下划线'_'组成,命名简洁明确,多个单词用下划线'_'分隔
(2)全部小写命名,禁止涌现大写
(3)禁止利用数据库关键字,如:name,time ,datetime,password等
(4)表名称不应该取得太长(一样平常不超过三个英文单词)
(5)表的名称一样平常利用名词或者动宾短语
(6)用单数形式表示名称,例如,利用 employee,而不是 employees
明细表的名称为:主表的名称+字符dtl(detail缩写)
例如:采购定单的名称为:po_order,则采购定单的明细表为:po_orderdtl
(7)表必须填写描述信息(利用SQL语句建表时)
2.2命名规范
①模块_+功能点 示例:alllive_log alllive_category
②功能点 示例:live message
③通用表 示例:all_user
2.3待优化命名示例
①冗余:
缺点示例:yy_alllive_video_recomment yy_alllive_open_close_log
解释:去除项目名,简化表名长度,去"yy_"
②相同种别表命名存在差异,管理性差
缺点示例:yy_all_live_category yy_alllive_comment_user
解释:去除项目名,统一命名规则,均为"yy_alllive_"开头即可
③命名格式存在差异
缺点示例:yy_showfriend yy_user_getpoints yy_live_program_get
解释:去除项目名,统一命名规则,动宾短语分离且动宾逻辑顺序统一
3、数据库字段命名规范3.1字段命名规范
(1)采取26个英笔墨母(区分大小写)和0-9的自然数(常常不须要)加高下划线'_'组成,命名简洁明确,多个单词用下划线'_'分隔
(2)全部小写命名,禁止涌现大写
(3)字段必须填写描述信息
(4)禁止利用数据库关键字,如: time ,datetime等
(5)字段名称一样平常采取名词或动宾短语
(6)采取字段的名称必须是易于理解,一样平常不超过三个英文单词
(7)在命名表的列时,不要重复表的名称
例如,在名employe的表中避免利用名为employee_lastname的字段
(8)不要在列的名称中包含数据类型
(9)字段命名利用完全名称,禁止缩写
3.2命名规范
①名词 示例:user_id user_name sex
②动宾短语 示例:is_friend is_good
3.3待优化命名示例
①大小写规则分歧一
缺点示例:user_id houseID
解释:利用统一规则,修正为"user_id","house_id"
②加下划线规则分歧一
缺点示例:username userid isfriend isgood
解释:利用下划线进行分类,提升可性,方便管理,修正为"user_name","user_id","is_friend","is_good"
③字段表示不明确
缺点示例:uid pid
解释:利用完全名称,提高可读性,修正为"user_id","parent_id"
3.4字段类型规范
(1)所有字段在设计时,除以下数据类型timestamp、image、datetime、smalldatetime、uniqueidentifier、binary、sql_variant、binary 、varbinary外,必须有默认值,字符型的默认值为一个空字符值串'',数值型的默认值为数值0,逻辑型的默认值为数值0
(2)系统中所有逻辑型中数值0表示为"假",数值1表示为"真",datetime、smalldatetime类型的字段没有默认值,必须为NULL
(3)用只管即便少的存储空间来存储一个字段的数据
利用int就不要利用varchar、char,
用varchar(16)就不要使varchar(256)
IP地址利用int类型
固定长度的类型最好利用char,例如:邮编(postcode)
能利用tinyint就不要利用smallint,int
最好给每个字段一个默认值,最好不能为null
(4)用得当的字段类型节约空间
字符转化为数字(能转化的最好转化,同样节约空间、提高查询性能)
避免利用NULL字段(NULL字段很难查询优化、NULL字段的索引须要额外空间、NULL字段的复合索引无效)
少用text类型(只管即便利用varchar代替text字段)
3.5数据库中每个字段的规范描述
(1)只管即便遵守第三范式的标准(3NF)
表内的每一个值只能被表达一次
表内的每一行都应该被唯一的标示
表内不应该存储依赖于其他键的非键信息
(2)如果字段事实上是与其它表的关键字干系联而未设计为外键引用,需建索引
(3)如果字段与其它表的字段干系联,需建索引
(4)如果字段需做模糊查询之外的条件查询,需建索引
(5)除了主关键字许可建立簇索引外,其它字段所建索引必须为非簇索引
4、SQL措辞编码规范4.1大小写规范
(1)所有关键字必须大写,如:INSERT、UPDATE、DELETE、SELECT及其子句,IF……ELSE、CASE、DECLARE等
(2)所有函数及其参数中除用户变量以外的部分必须大写
(3)在定义变量时用到的数据类型必须小写
4.2注释
注释可以包含在批处理中,在触发器、存储过程中包含描述性注释将大大增加文本的可读性和可掩护性,本规范建议:
(1)注释以英文为主,实际运用中,创造以中文注释的SQL语句版本在英文环境中不可用,为避免后续版本实行过程中发生某些非常缺点,建议利用英文注释
(2)注释尽可能详细、全面创建每一数据工具前,应详细描述该工具的功能和用场,传入参数的含义该当有所解释,如果取值范围确定,也该当一并解释,取值有特定含义的变量(如boolean类型变量),应给出每个值的含义
(3)注释语法:单行注释、多行注释
单行注释:注释前有两个连字符(--)对变量、条件子句可以采取该类注释
多行注释:符号之间的内容为注释内容,对某项完全的操作建议利用该类注释
(4)注释简洁,同时应描述清晰
(5)函数注释:
编写函数文本--如触发器、存储过程以及其他数据工具--时,必须为每个函数增加适当注释,该注释以多行注释为主,紧张构造如下:
CREATE PROCEDURE sp_xxx