java项目的安全性、稳定性、扩展性的一些总结
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
02 架构的安全性
5.机器模拟请求攻击
原因：黑客熟悉服务器临时token机制，通过代码不断获取临时token并且不断访问其他接口，造成服务器忙。 解决：在请求发送前提示输入验证码，输入密码口令等。
6. 身份伪造请求问题（包含CSRF跨域攻击）
原因：有两种形式。第一种为伪造网站，让用户在伪造网站处调用目标服务器的接口，通过验证并执行程序。第二种为黑客 通过抓包、XXS攻击等方式拿到持久性token（JWT、cookie等形式存到前台），然后通过该token伪造身份去访问请求，服务器接收 token后解析，执行程序。
解决：mybatis中使用#{name}形式拼接，底层jdbc会使用preparestamtement预编译方式拼接sql。而preparestamtement的本质 是将所有特殊符号比如=!()/等字符全部转义。
02 架构的安全性
3.防盗链
原因：其他网站、域名可以直接将本网站域名下的资源（可以是视频、图片等文件）引用，造成请求复用，没有访问本网站 资源却在其他网站发送静态请求获取资源。
}
01 代码的安全性
2.让不允许扩展每个类和方法都为 final
不允许扩展的类和方法应该声明为 final,这样做防止了系 统外的代码扩展类并修改类的行为 。
3.查找恶意代码
这样的恶意代码有三类:1.类中的 main 方法；2.定义过且未 使用的方法；3.注释中的死代码.
软件交付使用之前应该将（除启动应用程序的 main() 方法 之外的） main() 方法、未使用的方法以及死代码从应用程序代 码中除去
01 代码的安全性
5.线程安全
多线程访问时，采用了加锁机制，当一个线程访问该类 的某个数据时，进行保护，其他线程不能进行访问直到该 线程读取完，其他线程才可使用。不会出现数据不一致或 者数据污染
6.事务的应用
两张表甚至多张表中插入数据或者修改数据，这些数据都必 须保证一致，要么全成功要么全失败，不能有中间数据产生.
解决：第一种情况，因为不是服务器域名下可以采用禁止跨域，添加临时token，判断refere字段是否是本服务器白名单来解决。
第二种情况，因为是本服务器域名下，可以采用发送验证码，输入密码，验证身份等操作来保证是本人的操作。
02 架构的安全性
7. 上传文件漏洞
原因：通常在一些jsp项目中，上传的静态资源没有存放到静态资源服务器中，而是存到了项目中，如果不对文件类型进行限 制，黑客可以上传jsp文件并且在jsp文件中写上相应的java代码，直接调用该文件地址时就会执行内部的java代码，可能会危害整个 服务器上的文件。
01 代码的ห้องสมุดไป่ตู้全性
虚拟资产不能凭空产生，无限使用 1.向运营申请优惠券批次，批次中包含了此批优惠券的张数，申请原因等信息 2.业务需要发放优惠券时，先申请批次，再通过批次发放 资金出入必须与订单挂钩并且实现幂等 1.任何资金操作都必须有业务属性的订单。 2.实现幂等，且幂等处理必须是全链路的，使用相同的业务订单号作为三方支付ID,或者对两个ID进行固定格式的映射。
解决：给参数中的特殊字符进行编码encode，使用java默认的编码工具就行，不要对整个参数编码。
11.对称加密
对称加密是双方约定使用同一把秘钥进行加密和解密，常见的如DES、AES等。优点为加密解密相对快速省时间，缺点为 有泄露风险。因为加密解密是同一把秘钥，在一些C/S应用就很有可能被黑客反编译出源码，拿到加密的秘钥之后就可以破解 其他人的加密信息。使用场景：服务器内部之间调用，如服务器用httpClient、RPC通讯。
解决：java后台创建自定义过滤器，将请求中的所有<>这样的特殊字段全部转义成%lt格式。
2.sql注入
原因：后台sql拼接时没有用预编译格式，myabits中表现形式为${name}，底层jdbc表现形式为statement拼接。如:where password = '' or 1=1。另外，在一些项目中会有人使用java拼接sql语句，也会导致sql注入问题，因为sql在java中拼接不会进行转义。
4.避免硬编码敏感数据
您可能会尝试将诸如加密密钥之类的秘密存放在您 的应用程序或库的代码。对于你们开发人员来说，这样 做通常会把事情变得更简单。
将敏感数据保存在属性文件中，无论什么时候需要这 些数据，都可以从该文件读取。如果数据极其敏感，那 么在访问属性文件时，您的应用程序应该使用一些加密 ／解密技术。
17.Https请求
应用：简而言之https请求就是会自动加密数据并携带数字签名。https请求默认443端口，和http不是一个协议，默认会把带的 参数进行加密。想要使用https请求需要为自己域名申请一个SSL证书，如阿里云域名可以免费使用1年。htttps相对安全，谷歌浏览 器2018年以将https作为默认协议，没有带有证书的网站都会显示不安全。微信小程序必须是https协议，搜索引擎对https优先收录， 外网映射工具自带https协议。安全证书可以分配到nginx、tomcat、apach等服务器上，具体参考官方手册。
零零散散的异常。 区分清楚异常发生的原因，然后决定你的异常
是检查异常还是运行时异常。
01 代码的安全性
8.涉及钱时，必须考虑的防刷，限量和防重
日常开发，涉及钱的代码，主要三类：1.有偿使用三方服务（例如：短信验证码服务）;2.代码涉及虚拟资产的发放（积分和优 惠券）3.代码涉及真实资金的进出。
短信验证码防刷：1.固定的请求头才能发送验证码（防爬虫），请求头加额外的参数，判断是否存在浏览器，手机型号，设备分 辨率请求头.
解决：重要数据全部放到后台服务器上存取，前台只发送添加信息。
02 架构的安全性
9. 开放接口的安全性设计
应该有token机制防范模拟请求攻击和幂等性问题,必须保证是本系统去调用而不是其他系统
10. URL漏洞
原因：传输数据时如果url上带有特殊字符，比如=+/？等，传输时如果不做特殊处理时会丢失信息，以httpClient为例，A传给B 的数据没有参数中的特殊字符进行处理，B最后得到的数据就会是错误的。
2.只有通过注册页面才能发送验证码（防直接调用接口）,在界面打开时，请求固定的前置接口，为设备开启允许发送验证码的 窗口，只有这样请求才有效。
3.控制相同手机号的发送此时和发送频率（1天10次，最短间隔1分钟） 4.添加前置图形验证码（比如滑动，点击验证），为提升用户体验，可采取无感知验证方案（通过判断用户输入手机号的打字 节奏，来判断是用户还是机器）
5.多线程在未发生线程安全前提下应尽量使用HashMap、ArrayList
HashTable、Vector等使用了同步机制，降低了性能。
02 架构的安全性
16.非对称加密
非对称加密一般是说利用一对公钥加密，私钥解密，常见的如有RSA。优点为相对安全，缺点为解析费事效率低。秘钥存到服 务器上黑客难以获取到，公钥存到客户端，即使被破解也无法解析出原来的信息。开发人员提前用utils类生成一对公钥私钥保存到 服务器上，之后用utils进行加密解密。还有最近流行的Bcrypt属于特殊的非对称加密，每次加密的结果都不一样，但是可以通过和 结果对比确定是否正确。使用场景：C/S结构的项目，如APP，PC客户端
项目安全性、性能的一些 总结
01 安全性
安全产品分析
01 代码的安全性
1.限制对变量的访问
如果将变量声明为 public，那么外部代码就 可以操作该变量。这可能会导致安全性暴露。
一般来说，应该使用取值方法而不是 public 变量。按照具体问题具体对待的原则，在确定 哪些变量特别重要因而应该声明为 private 时， 创建适当的get和set方法并使用它们。
01 代码的性能调优
4.慎用synchronized，尽量减小synchronize的方法
实现同步是要很大的系统开销作为代价的，甚至可能造成死锁，所以尽量避免无谓的同步控制。synchronize方法 被调用时，直接会把当前对象锁 了，在方法执行完之前其他线程无法调用当前对象的其他方法。所以synchronize的方 法尽量小，并且应尽量使用方法同步代替代码块同步。
尽量避免在经常调用的方法，循环中new对象，由于系统不仅要花费时间来创建对象，而且还要花时间对这些 对象进行垃圾回收和处理，在我们可以控制的范围内，最大限度的重用对象，最好能用基本的数据类型或数组来替代 对象。
3.尽量使用局部变量
调用方法时传递的参数以及在调用中创建的临时变量都保存在栈（Stack）中，速度较快。其他变量，如静态变 量，实例变量等，都在堆（Heap）中创建，速度较慢。
同样的请求被执行一次与执行多次效果是一样的，服务器的状态 也是一样的，实际上就是接口的可重复调用
02 架构的安全性
1.XXS攻击
原因：XXS攻击是js脚本攻击，将网站上传给后台的参数设置成js脚本格式：<script>...<script/>格式，当另外一个页面需要展示 这个参数时就会加载此参数，从而造成<body>${name}<body/>变成<body><script>...<scritp/><body/>形式，执行脚本文件。黑客会 利用此漏洞进行页面非法跳转等，如钓鱼网站，或尝试用js读取本地cookie文件信息后发送给自己。
解决：只对文件后缀进行判断无法阻止黑客上传可运行文件，正规做法是通过文件流的拼接，根据文件流字段上的二进制数 据转成字符，根据字符判断文件类型。
8. 前端漏洞
原因：部分系统讲用户的ID，手机号等信息保存在前端cookie或者隐藏域中，cookie中若不加密很可能会被别人篡改，同理隐 藏域也是可以被篡改，在一些接口访问时会读取这些数据，造成他人数据泄露。
02 性能
广义性能调优鱼骨图
性能调优步骤图
性能调优思路
01 代码的性能调优
1.尽量避免随意使用静态变量
当某个对象被定义为static变量所引用，那么GC通常是不会回收这个对象所占有的内存，如：此时静态变量b的 生命周期与A类同步，如果A类不会卸载，那么b对象会常驻内存，直到程序终止。
2.尽量避免过多过常的创建Java对象
还有分布式事务的场景，比如多个数据库实例，要求数据的 一致性，操作多个数据库，确保数据都更新，或者都不更新
7.正确使用Java异常处理机制
确定什么场景下，需要创建自己的异常类型。 为你的接口方法的使用规则创建一组运行时异
常。 包装别人的检查异常的时候，一定也要用检查
异常这样异常才能传递给上层方法处理。 设计一组有层次结构的异常，而不是设计一堆
class Test { private int id; private String name; Test(){ id = 1; name = "hello world"; } public void setId(int id){ this.id = id; } public void setName(String name){ = name; } public int getId(){ return id; } public String getName(){ return name; }
解决：通过自定义filter，在filter处判断reference 字段，根据字段名称去数据库查询相应的域名，如果等于数据库中的白名单 就放行，如果不等于就返回一张错误图片回去。可以放到网关处对静态资源进行优先判断
4.网络延迟引起的接口幂等性
原因：因为网络延迟或者用户多次点击等原因，前台向后台发送多个请求，在表单提交处可能会引起多次提交造成数据重复。 解决：不推荐悲观锁实现，建议使用临时token（实际最常用办法），在进入页面时，或者在发送请求前，就在后台生成一个唯 一token存进session、redis、或一个IOC容器（CurrentHashMap）中，将生成的token返回给前台。前台发送请请求时带上token信息， 前台一般可以存在隐藏input中或者，先从容器中取出并移除token，并重新生成一个唯一token存进容器，返回给前台。此办法可以 解决多次提交性问题。临时token推荐使用注解形式实现。