安全相关规范

雪神
706 阅读12分钟

操作系统安全

账户安全

所有的在用服务器用户密码避免使用 admin/root等敏感关键词 密码必须是字母+数字+特殊字符的复杂组合

中间件安全

服务器所部署中间件必须定期进行漏洞查找，避免因为中间件漏洞被攻击

可疑程序

定期排查服务器可以进程，进而排查可疑程序尤其挖矿类程序

移动设备载体安全

客户现场使用的移动设备，必须使用加密U盘,禁止使用非加密优盘直接接入内网电脑设备

代码安全规范

系统弱口令

   应用系统必须用户密码避免使用 admin/root等敏感关键词 密码必须是字母+数字+特殊字符的复杂组合

非法数据录入

恶意的攻击者会尝试在用户界面或接口中向系统输入恶意数据，以便期望绕过系统的安全限制，致使系统出甚至崩溃或其他非法目的，因此在编码时，须要对所有输入数据 (包括用户在界面中输入的数据和其他应用系统通过接口传递的数据)进行严格的合法性检查。

SQL注入

SQL 注入式（SQL Injection）攻击是一种典型的，因对输入数据不当处理而产生的非常严重的安全漏洞。其原因是基于数据库的应用程序中经常会使用动态 SQL 语句，而且在程序又没有对输入数据严格检查，致使攻击者能在界面层或接口层注入非法的 SQL 语句，从而非法访问和破坏数据、反向工程、甚至对服务器本身造成威胁。对于攻击者来说，SQL注入式攻击是一种简单有效的攻击方式，也是首选方式，尤其是在基于 Web的应用程序中，因此开发人员必须重点关注此问题。
预防 SQL注入式攻击的手段就是严格检查用户输入的数据，要使用基础系统提供的参数化查询接口，避免使用字符串来构造动态 SQL查询。同时对于数
据库对象的访问权限进行严格限制，避免恶意 SQL语句破坏数据或系统。

例子

Select * from sys_user where uusername = XXX

把XXX改成

or 1=1

这样就变成了

Select * from sys_user where uusername = '' or 1=1

预防攻略

  1. 所有的查询语句都使用数据库提供的参数化查询接口，参数化的语句使用参数而不是将用户输入变量嵌入到SQL语句中。当前，几乎所有的数据库系统都提供了参数化SQL语句执行接口，使用此接口可以非常有效的防止SQL注入攻击。
  2. 对进入数据库的特殊字符（'"<>&*;等）进行转义处理，或编码转换。
  3. 确认每种数据的类型。比如：数字型的数据就必须是数字，数据库中的存储字段必须对应为int型。
  4. 数据长度应该严格规定，能在一定程度上防止比较长的SQL注入语句无法正确执行。
  5. 每个数据层的编码统一，建议全部使用UTF-8编码，上下层编码不一致有可能导致一些过滤模型被绕过。
  6. 严格限制用户的数据库的操作权限，给此用户提供仅仅能够满足其工作的权限，从而最大限度的减少注入攻击对数据库的危害。
  7. SQL注入种类，方式变换繁多，并不能做全数说明，所提内容均为基础说明，以提醒警示为主。

敏感信息泄露

攻击者可能会通过暴力攻击、侦听、截取中间数据、反向工程、社会工程学（Social Engineering）等手段，获取访问凭据或机密信息，危及数据的私有性/安全性或者暴露敏感的商业数据，如用户名/口令、加密密钥、数据库连接串、商业敏感信息等。因此在处理这些数据时，必须利用以密码技术为主的安全技术来进行强有力的机密性保护。在使用密码技术时，一般要利用公开的、经过广泛验证的可靠加密算法，同时加强密钥的管理和保护

XSS攻击

为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆，故将跨站脚本攻击缩写为XSS。恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意攻击用户的特殊目的。

预防攻略

  • 要假定所有输入都是可疑的，必须对所有输入中的script、iframe等字样进行严格的检查。这里的输入不仅仅是用户可以直接交互的输入接口，也包括HTTP请求中的Cookie中的变量，HTTP请求头部中的变量等。
  • 不仅要验证数据的类型，还要验证其格式、长度、范围和内容。
  • 不要仅仅在客户端做数据的验证与过滤，关键的过滤步骤在服务端进行。
  • 对输出的数据也要检查，数据库里的值有可能会在一个大网站的多处都有输出，即使在输入做了编码等操作，在各处的输出点时也要进行安全检查。

暴力破解:

攻击者可以利用该漏洞暴力破解出系统存在弱口令的账号，从而为进一步攻击提供基础

预防攻略

  • 1、建议采用锁定机制：如限制单位时间内执行某项操作的次数（如果次数超过则对账号或IP进行一段时间的锁定，锁定时间内不得使用相关功能，应对限制方式、次数和计算方法、锁定时间等进行明确的说明。） ；
  • 2．建议采用人机识别措施：如图片验证码、重力感应、短信验证码、语音验证码等，为了提升用户体验，对于一些低风险的操作，可以设定单位时间内执行操作次数的阀值，超过阀值后再进行人机识别措施；
  • 3．图片验证码不应选择简单的数字图片，应加入干扰线、变形、颜色、汉字或者其他机器较难识别的逻辑来提升人机识别的有效性；
  • 4．验证码的生存周期应为一次性，即无论校验成功或失败，验证码在一次校验后就应该失效；
  • 5．所有的人机识别措施和校验都应在服务端进行；
  • 6．验证过程中不应返回有助于推测正确验证答案的信息，比如返回验证码的内容回客户端。

水平越权

攻击者可以利用该漏洞修改其他同权限人员的密码，还可查看增加删除其他同权限人员的信息

预防攻略

  • 1、使用安全配置，对敏感服务接口使用白名单访问控制列表；
  • 2．验证一切来自客户端的参数，重点是和权限相关的参数，比如用户ID或者角色权限ID等；
  • 3．session ID 和认证的token做绑定，放在服务器的会话里，不发送给客户端；
  • 4．对于用户登录后涉及用户唯一信息的请求，每次都要验证检查所有权，敏感信息页面加随机数的参数，防止浏览器缓存内容；
  • 5．把程序分成匿名，授权和管理的区域，通过将角色和数据功能匹配。
  • 6．不使用参数来区分管理员和普通用户；
  • 7．服务端需校验身份唯一性，自己的身份只能查看、修改、删除、添加自己的信息#

CSRF漏洞攻击(跨站攻击)

CSRF（Cross-site request forgery）跨站请求伪造：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。
常见攻击场景

GET 类型CSRF

<img src=http://xxx.org/csrf.php?xx=1 />
访问页面后就成功向http://xxx.org/csrf.php 发送了一次请求
<link href="…">
<iframe src="…">
<meta http-equiv="refresh" content="0; url=…">
<script src="…">
<video src="…">
<audio src="…">
<a href="…">
<table background="…">

POST类型的CSRF 使用一个自动提交的表单

<form action=http://woyun.org/csrf.php method=POST>
<input type="text" name='xx' value='11' />
</form>
<script>document.forms[0].submit();</script>

模拟用户完成了一次POST操作 也可以用JS动态生成

防御策略

通常情况下，有三种方法被广泛用来防御CSRF攻击：验证token，验证HTTP请求的Referer，还有验证XMLHttpRequests里的自定义header。建议使用Token验证。

任意文件上传

任意文件上传漏洞，攻击者可以通过该漏洞任意上传木马等文件，达到提权服务器等目的。

预防策略

客户端以及服务端对上传文件类型以及文件大小进行限制。

Cookies复用

攻击者可以利用该漏洞直接登录其他用户的账户，无需用户口令。

预防策略

  • 1.用户登录前如果检查到已经是登录状态，销毁旧会话，生成新的会话，强制旧用户下线；
  • 2．设置Cookie有效期；
  • 3．给Cookie添加Httponly属性。

网络安全

服务器端口尽量少开或者不开
敏感端口如果必须要开做端口转换 如 80 换成 3421

移动应用安全

敏感数据数据必须加密保存

（1）、采取权威的主流加密算法（如DES、AES、RSA等） （2）、选取秘钥的长度必须足够长，以便满足安全性要求。 （3）、加密算法的实现方法，必须采用操作系统官方提供的接口，或是各语言标准算法库提供的函数。 （4）、严禁自己设计、实现机密算法

网络传输必须走https，服务端证书必须由权威的CA机关提供

加固壳

  • 使用主流的加固厂商提供的专业加固方案 腾讯的乐固或者360的安全加固

Java代码反编译风险

  • 使用具有防反编译功能的第三方专业加固方案，防止应用被反编译

本地数据存储安全

  • 通过设置WebView.getSettings().setSavePassword(false)关闭webview组件的保存密码功能
  • Webview File同源策略绕过漏洞
  1. 将不必要导出的组件设置为不导出，并显式设置所注册组件的“android:exported”属性为false；
  2. 如果需要导出组件，禁止使用File域 WebView.getSettings.setAllowFileAccess(false);
  3. 如果需要使用File协议，禁止File协议调用JavaScript： WebView.getSettings.setJavaScriptEnabled(false)
  • 动态调试攻击风险

使用具有反动态调试功能的第三方专业加固方案，防止应用被动态调试。

  • 应用数据任意备份风险

将allowBackup的属性显式设置为false，以关闭应用数据备份功能；或者使用具有本地数据加密功能的第三方专业加固方案，避免本地数据泄露。、

  • 动态注入攻击风险

使用具有反动态注入功能的第三方专业加固方案，防止应用被动态注入。

  • Webview远程代码执行漏洞

取消使用addJavascriptInterface接口，以其他Java与JavaScript互通方案代替；若必须使用，则应对访问的url进行过滤限制或对html页面进行完整性校验，同时显示移除对指定的javascript接口的调用： removeJavascriptInterface ("searchBoxJavaBridge_"); removeJavascriptInterface ("accessibility"); removeJavascriptInterface ("accessibilityTraversal")；

  • 未移除有风险的Webview系统隐藏接口漏洞

开发者显式移除有风险的Webview系统隐藏接口。 以下为修复代码示例： 在使用Webview加载页面之前，执行 webView.removeJavascriptInterface("searchBoxJavaBridge_"); webView.removeJavascriptInterface("accessibility"); webView.removeJavascriptInterface("accessibilityTraversal");

关于加密算法

这几种加密弱点是不安全的：

  • ①使用不安全的加密算法。加密算法强度不够，一些加密算法甚至可以用穷举法破解。
  • ②加密数据时密码是由伪随机算法产生的，而产生伪随机数的方法存在缺陷，使密码很容易被破解。
  • ③身份验证算法存在缺陷。
  • ④客户机和服务器时钟未同步，给攻击者足够的时间来破解密码或修改数据。
  • ⑤未对加密数据进行签名，导致攻击者可以篡改数据。所以，对于加密进行测试时，必须针对这些可能存在的加密弱点进行测试。

算法分类

国密即国家密码局认定的国产密码算法。主要有SM1，SM2，SM3，SM4。密钥长度和分组长度均为128位。
  • SM1 为对称加密。其加密强度与AES相当。该算法不公开，调用该算法时，需要通过加密芯片的接口进行调用。
  • SM2为非对称加密，基于ECC。该算法已公开。由于该算法基于ECC，故其签名速度与秘钥生成速度都快于RSA。ECC 256位（SM2采用的就是ECC 256位的一种）安全强度比RSA 2048位高，但运算速度快于RSA。
  • SM3 消息摘要。可以用MD5作为对比理解。该算法已公开。校验结果为256位。
  • SM4 无线局域网标准的分组数据算法。对称加密，密钥长度和分组长度均为128位。

本篇文章由一文多发平台ArtiPub自动发布

avatar
文章
阅读
粉丝