OWASP_TOP10

发表于 2019-07-26 更新于 2021-02-19 阅读次数： Valine：
本文字数： 6.7k 阅读时长 ≈ 6 分钟

OWASP全称Open Web Application Security Project，即开源应用程序安全项目。OWASP TOP为该项目每年发布的最具权威的就是其”十大安全漏洞列表”。

1.注入

sql注入等

危害：导致数据丢失或数据破坏

常见混淆方式：

1.使用注释来进行截断

http://victim.com/news.php?id+un/*//ion+se/*/lect+1,2,3—

2.变换大小写

http://victim.com/news.php?id=1+UnIoN SeLecT 1,2,3—

3.替换关键词(将关键词插在关键词中)

http://victim.com/news.php?id=1+UNunionION+SEselectLECT+1,2,3--

解决方法：

1.最佳方法：采用sql语句预编译和绑定变量

采用了PreparedStatement，就会将sql语句：”select id, no from user where id=?” 预先编译好，也就是SQL引擎会预先进行语法分析，产生语法树，生成执行计划，也就是说，后面你输入的参数，无论你输入的是什么，都不会影响该sql语句的语法结构了，因为语法分析已经完成了，而语法分析主要是分析sql命令，比如 select ,from ,where ,and, or ,order by 等等。所以即使你后面输入了这些sql命令，也不会被当成sql命令来执行了，因为这些sql命令的执行，必须先的通过语法分析，生成执行计划，既然语法分析已经完成，已经预编译过了，那么后面输入的参数，是绝对不可能作为sql命令来执行的，**只会被当做字符串字面值参数**。所以sql语句预编译可以防御sql注入。

2.一些特殊情况不能sql语句预编译的，可以进行严格的输入检查，限制输入数据类型、过滤关键字、使用正则表达式限制等

sql注入方式写入webshell：

用工具对目标站直接写入一句话条件:root权限以及绝对路径

方式：

1.

(1)创建自己的数据库 http://www.aspx-sqli.com/index.asp?id=1;create%20database%20zhong;

(2)先进行一次完整备份： ?id=1;backup database zhong to disk = ‘E:\wwwroot\asp_sqli’;

(3)创建新表：在数据库名为中的库里面创建一个新的cmd表 create table [dbo].[zhong] ([cmd] [image]);

(4)向cmd表中插入数据 ?id=1;insert into zhong(cmd) values(0x3C25657865637574652872657175657374282276616C7565222929253E);

(5)进行数据库的差异备份 ?id=1;backup database zhong to disk=’E:\wwwroot\asp_sqli\zhongqzi.asp’ WITH DIFFERENTIAL,FORMAT;

(6)菜刀连接

2.跨站脚本攻击

当应用程序在发送给浏览器的页面中包含用户提供的数据，但没有经过适当的验证或转义就会导致快粘脚本漏洞。

分类

1.反射性xss

又称为非持久性跨站点脚本攻击，它是最常见的类型的XSS。漏洞产生的原因是攻击者注入的数据反映在响应中。一个典型的非持久性XSS包含一个带XSS攻击向量的链接(即每次攻击需要用户的点击)。

例：

正常发送消息：

http://www.test.com/message.php?send=Hello,World！

接收者将会接收信息并显示Hello,Word

非正常发送消息：

http://www.test.com/message.php?send=！

接收者接收消息显示的时候将会弹出警告窗口

2.存储型xss

又称为持久型跨站点脚本，它一般发生在XSS攻击向量(一般指XSS攻击代码)存储在网站数据库，当一个页面被用户打开的时候执行。每当用户打开浏览器,脚本执行。持久的XSS相比非持久性XSS攻击危害性更大,因为每当用户打开页面，查看内容时脚本将自动执行。

例：

留言板表单中的表单域：

正常操作：

用户是提交相应留言信息；将数据存储到数据库；其他用户访问留言板，应用去数据并显示。

非正常操作：

攻击者在value填写或者html其他标签（破坏样式。。。）、一段攻击型代码】；

将数据存储到数据库中；

其他用户取出数据显示的时候，将会执行这些攻击性代码

3.DOM型xss

当用户能够通过交互修改浏览器页面中的DOM(DocumentObjectModel)并显示在浏览器上时，就有可能产生这种漏洞，从效果上来说它也是反射型XSS。

　　通过修改页面的DOM节点形成的XSS，称之为DOMBasedXSS。

　　前提是易受攻击的网站有一个HTML页面采用不安全的方式从document.location 或document.URL 或 document.referrer获取数据（或者任何其他攻击者可以修改的对象）。

例：

欢迎页面中name是截取URL中get过来的name参数

正常操作：

http://www.vulnerable.site/welcome.html?name=Joe

非正常操作：

http://www.vulnerable.site/welcome.html?name=

危害：攻击者能够在受害者浏览器中执行脚本以及劫持用户会话、迫害网站、插入恶意内容等

防范

1.将重要的cookie设置为http only(这样Javascript 中的document.cookie语句就不能获取到cookie了)

3.过滤或移除特殊的Html标签，例如:
解码后为,一样可以弹窗

利用点:当js解释器在标识符名称(例如函数名，属性名等等)中遇到unicode编码会进行解码，并使其标志符照常生效

为什么常常将DOM型xss单独列出？DOM型xss和其他两种有什么区别？

因为DOM型主要是由于浏览器解析机制导致的，不需要服务器进行参与，而剩余两种都是需要服务器响应参与

设置了cookie 为http only，xss还有什么方法可以获取到cookie？

1.php类型的网站可以用phpinfo()

2.

3.跨站请求伪造(CSRF)

CSRF，全称为Cross-Site Request Forgery，跨站请求伪造，是一种网络攻击方式，它可以在用户毫不知情的情况下，以用户的名义伪造请求发送给被攻击站点，从而在未授权的情况下进行权限保护内的操作。具体来讲，可以这样理解CSRF。攻击者借用用户的名义，向某一服务器发送恶意请求，对服务器来讲，这一请求是完全合法的，但攻击者确完成了一个恶意操作，比如以用户的名义发送邮件，盗取账号，购买商品等等。

原理

Web A为存在CSRF漏洞的网站，Web B为攻击者构建的恶意网站，User C为Web A网站的合法用户。

用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；并且，此后从用户浏览器发送请求给网站A时都会默认带上用户的Cookie信息；
　　
用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B；网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；

浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行

CSRF必须步骤

1.用户访问可信任的网站并产生了cookie

2.用户在访问A站点时没有退出，同时访问了恶意站点B

防范

1.给每一个HTTP添加一个不可预测的令牌，并保证该令牌对每个用户会话来说是唯一的，并且不再URL中进行显示

2.验证HTTP referer字段

XSS和CSRF的区别

1.能否cookie获取：

CSRF无法获取用户的cookie，只是诱导受害者使用被服务器信任的cookie取执行攻击者构造好的请求

XSS可以获取cookie

2.漏洞利用前提

CSRF攻击需要用户已经对登陆了目标网站

XSS不需要用户已经登陆了目标网站

3.原理区别

CSRF是利用网站本身的api去进行攻击

XSS是向网站中获请求中嵌入js代码，通过执行js进行攻击

4.其他安全问题

waf和ips的绕过区别和一些技巧

2.失效的身份认证和会话管理

身份认证：身份认证最常用于系统登录，形式一般为用户名和密码登录方式，在安全性要求较高的情况下，还有验证码、客户端证书、Ukey等

会话管理：HTTP利用会话机制来实现身份认证，HTTP身份认证的结果往往是获得一个令牌并放在cookie中，之后的身份识别只需读授权令牌，而无需再次进行登录认证

攻击原理

开发者通常会建立自定义的认证和会话管理方案。但与身份认证和回话管理相关的应用程序功能往往得不到正确的实现，要正确实现这些方案却很难，结果在退出、密码管理、超时、密码找回、帐户更新等方面存在漏洞，这就导致了攻击者攻击者破坏密码、密钥、会话令牌或攻击其他的漏洞去冒充其他用户的身份（暂时或永久的）

产生原因

1.用户的身份认凭证(url中的id、cookie等)没有使用哈希或加密保护

2.会话ID暴露在URL里

3.会话ID没有超时限制，或超时限制不合理

4.认证凭证存在规律，可以直接通过猜测获得

防范

1.cookie和url中的身份凭证进行加密

2.设置密码和会话的有效期，并强制使用强密码

3.账号密码以密文形式传输在数据中hash存储

4.不安全对象的直接引用

不安全的直接对象引用，也被称IDOR。IDOR允许攻击者绕过网站的身份验证机制，并通过修改指向对象链接中的参数值来直接访问目标对象资源，这类资源可以是属于其他用户的数据库条目以及服务器系统中的隐私文件等等。

常见攻击形式：

目录遍历

假设 Web 应用程序允许为要呈现给用户存储在本地计算机上的文件。如果应用程序不验证应访问哪些文件，攻击者可以请求其他文件系统上的文件和那些也会显示。

例如，如果攻击者通知 URL:
https://oneasp.com/file.jsp?file=report.txt

攻击者可以修改文件参数使用目录遍历攻击。他修改的 URL:
https://oneasp.com/file.jsp?file=**../../../etc/shadow**

这样 /etc/阴影文件返回并且呈现由 file.jsp 演示页面容易受到目录遍历攻击。

开方重定向

Web 应用程序有一个参数，允许其他地方的用户重定向到网站。如果此参数不实现正确使用白名单，攻击者可使用这一网络钓鱼攻击引诱到他们选择的站点的潜在受害者。

例：

例如，如果攻击者通知 URL:
https://oneasp.com/file.jsp?file=report.txt

攻击者可以修改文件参数使用目录遍历攻击。他修改的 URL:
https://oneasp.com/file.jsp?file=**../../../etc/shadow**

防范：

1.验证用户输入的url请求，拒绝包含../和./的请求

2.锁定服务器上的

5.安全配置错误

良好的安全性需要为应用程序、框架、应用服务器、web服务器、数据库服务器和平台定义和部署安全配置。默认值通常是不安全的。

攻击案例

案例#1：应用程序服务器管理员控制台自动安装后没有被删除。而默认帐户也没有被改变。攻击者在你的服务器上发现了标准的

管理员页面，通过默认密码登录，从而接管了你的服务器。
案例#2：目录列表在你的服务器上未被禁用。攻击者发现只需列出目录，她就可以找到你服务器上的任意文件。攻击者找到并下载所有已编译的Java类，她通过反编译获得了所有你的自定义代码。然后，她在你的应用程序中找到一个访问控制的严重漏洞。
案例三：

1）打开IISPutScanner.exe应用扫描服务器,输入startIP192.168.1.119和endIP192.168.1.119(也可以对一个网段进行设置) ,点击Scan

进行扫描,PUT为YES服务器类型为IIS ,说明可能存在IIS写权限漏洞。

（2）使用iiswrite.exe应用,使用此软件来利用IIS写权限漏洞上传一句话木马。

1.以PUT方式上传22.txt文件。检查目标网站是否有test.txt文件显示出错,说明没有 test.txt文件,那么我们可以请求的文件名可以为22.txt。域名为192.168.1.119,点击提交数据包。重新访问 192.168.1.119/test.txt显示上传内容,说明上传成功。

2.使用COPY方式复制一份数据,数据的文件名为shell.asp,点击提交数据。使用浏览器访问http://192.168.1.119/shell.asp发现访问成功,没有出错,说明复制成功。

3.打开中国菜刀,鼠标右键点击添加输入地址http://192.168.1.119/shell.asp密码为chop per点击添加。双击打开连接,获取到服务器的目录,看到有上传的shell.asp文件和 test.txt文件。

防范

1.了解并及时部署每个环境的软件更新和补丁信息

2.统一出错处理机制，错误处理会向用户显示堆栈跟踪获其他归于丰富的错误消息信息。

3.使用提供有效分离和安全性强大的应用程序架构

6.敏感信息泄露

常见的漏洞是应该进行加密的数据没有进行加密。使用加密的情况下常见问题是不安全的密钥和使用弱算法加密。

敏感数据包括哪些？

1.个人信息

2.网站登录用户名、密码、SSL证书、会话ID、加密使用的秘钥等

3.Web服务器的系统类型、版本、Web服务器信息、数据库信息等

防范

1.个人信息数据加密存储

2.敏感数据的传输使用SSL加密传输

3.应用程序出错的信息不直接显示在页面上，统一错误页面

7.缺少功能级的访问控制

功能级的保护是通过系统配置管理的，当系统配置错误时，开发人员必须做相应的代码检查，否则应用程序不能正确的保护页面请求。攻击者就是利用这种漏洞访问未经授权的功能模块。

很多系统的权限控制是通过页面灰化或隐藏URL实现的，没有在服务器端进行身份确认和权限验证，导致攻击者通过修改页面样式或获取隐藏URL，进而获取特权页面来对系统进行攻击，或者在匿名状态下对他人的页面进行攻击，从而获取用户数据或提升权限。

此类问题主要是系统在开发或者设计阶段，没有考虑攻击场景，以为看不到就是安全的，这种系统说白了是服务端没有进行权限控制和身份校验，才给了攻击者可乘之机。

防范

1.设置严格的权限控制系统，尤其是服务端必须进行权限和身份验证

2.默认缺省情况下，应该拒绝所有访问的执行权限

3.对于每个功能的访问，都要有明确的角色授权，采用过滤器的方式校验每个请求的合法性

矩形搜索、遍历相关算法

发表于 2019-07-25 更新于 2021-02-19 阅读次数： Valine：
本文字数： 265 阅读时长 ≈ 1 分钟

1.矩阵中的路径

请设计一个函数，用来判断在一个矩阵中是否存在一条包含某字符串所有字符的路径。路径可以从矩阵中的任意一个格子开始，每一步可以在矩阵中向左，向右，向上，向下移动一个格子。如果一条路径经过了矩阵中的某一个格子，则之后不能再次进入这个格子。例如 a b c e s f c s a d e e 这样的3 X 4 矩阵中包含一条字符串”bcced”的路径，但是矩阵中不包含”abcb”路径，因为字符串的第一个字符b占据了矩阵中的第一行第二个格子之后，路径不能再次进入该格子。

关键点：1.该问题很容易可以看出是回溯问题，在回溯问题上最好不要使用直接的队列删除

常见文件解压命令

发表于 2019-07-25 更新于 2021-02-19 阅读次数： Valine：
本文字数： 50 阅读时长 ≈ 1 分钟

Rar文件解压

1.查看不解压

1	unrar l filename.rar

2.带路径解压

1	unrar x filename.rar

3.不带路径解压(全部在文件夹内的内容全部解压到当前目录)

1	unrar e filename.rar

秋招面经

发表于 2019-07-23 更新于 2021-02-19 阅读次数： Valine：
本文字数： 3.4k 阅读时长 ≈ 3 分钟

作业帮

作为秋招的首个面试，时间在晚上7点到9点半，面试过程中听到边上大佬在介绍工作时间，大小周制，早10点到晚9点，标准的互联网工作制吧，整体感觉还行，一次面了两面，感觉已经凉凉了，下面是面经：

一面

上来直接拿一张纸直接开始写代码：一道题分三问：(1)声明数据结构，存储节点 (2)给定前序遍历序列，；例如：adcv*dsf，”\代表空”，恢复二叉树 (3)得到后续遍历序列题目不难，但是第二问脑袋抽筋了，想了很久才写出来。。。接下来是一道决策求期望的问题，给一枚色子投到几就能够获得几枚金币，第一次投掷后可以选择是否重新投掷，问如何进行决策才能获得最大期望以及最大期望值。

二面

问项目，感觉对项目并不是很感兴趣甚至有点嫌弃…，不说了直接上问题。主要写了四道题吧，第一个机器人寻路问题，在一个m*n的网格中，有多少条路线可以走到终点，好像是剑指offer上的题目吧,递归很简单。第三个问题是一个概率问题，就是5枚硬币，一枚正面为字背面为人，两枚正反都为人，两枚正反都为字，随机投一枚硬币发现朝上的是字，问另一面也是字的概率，一个典型的贝叶斯估计问题。第四个合并两个二叉搜索树，思路就是先中序遍历两个序列存在数组中，然后合并两个排序数组，在重建二叉搜索树，但是！这里中序遍历的非递归我居然没写出来！！！。

百度大搜

一面

面试官说的两句话还是挺让人印象深刻的，做模型关键点不在模型算法上，更关键的应该是数据标注和特征提取，之前一直觉得机器学习才是这样，深度学习更主要的模型结构的设计，基本上没有怎么注意特征提取、数据标注，尤其是数据标注，面试官说在真正的大数据场景下是没法使用规则、人工标注的，更多的还是需要采用一定的高级自动化方式。

编程题：1.求非递减数组各个元素平方后组成的非递减数组

2.

两个场景题目：

1.两个文件中存储两个表，表1中存储id,name,locate,表2中存储id,phone，如何合并两个表（内存不支持两个表完全读入）？他最后的提示是map-reduce思想

2.一个衡量两个query query1和query2语义是否相同的项目，如何进行数据标注，模型结构设计？

数据标注可以结合行为数据进行标注，这种准确度很高，不太需要再去人工调整

直接凉凉…

百度安全

超长时间面试，从中午11点直接三面面到了下午4点，晕… 希望能有个好结果吧

一面

一上来直接拿了一张纸，上面有3到编程题，3选2，题目都很简单，一道获取数组整数下界，另一道不记得了，然后是算法型题目，记得的1.什么是生成模型、判别模型，两者的应用场景 2.有监督学习黑白样本不均衡对建模有什么影响？怎么去解决？ 3.解释什么是概率什么是似然，二者分别在什么情况下进行应用？ 4.xgbt是如何进行剪枝的？ 5.模型的评价指标都有什么？计算公式 6.三种集成学习都是什么？具体介绍一下是如何进行集成的 然后问了一些模型方面的问题 word2vec原理，有哪两种？优化方式有哪两种？这里问到了具体的word2vec是怎么进行训练的，不是很清楚具体细节，答的不太好 还有就是BN在训练和预测时有什么不同 LR和决策树分别用于什么情况？决策树更适用连续数据还是离散数据？这里我答的是离散，面试官提示说说连续，其实还不是很懂 Kmeans、高斯混合模型其他就是项目相关的问题的了，大体上就是这些，整体感觉确实很偏向算法基础

二面

这一面主要是问项目的一些细节，包括LSTM、Bert等一些细节问题然后让写了一道算法题，一个矩阵，从左上角走到右下叫最小的路径。

三面

前后来了两个面试官，一个是大数据方向的，和我聊了聊我说对大数据没有太深的了解就换了面试官，这次的面试官看样子像个领导，主要就是聊项目、应用等，最后介绍了下他们这边的情况还有这个岗位的情况

9月底才有消息，等的我真是怕了

阿里云安全

一面

下午突然接到的电话面大约30min，面试官人很好，首先就介绍了他们这边的工作，然后才让我做的自我介绍，自我介绍在，项目聊了很久，然后就是模型、web安全、协议、Linux四个方面基础知识的一些问题，模型方面问决策树是如何决定节点怎么进行分裂的？SVM的核函数是做什么的？ web安全方面：什么是csrf？如何进行防御？什么是xss都有哪几类？DOM型和其他两种类型有什么不同？ 协议方面：是否了解traceroute,整个路径跟踪过程是如何实现的？

全部都面完以后才知道这个面试官就是我以后的leader，人真的很好，感觉很幸运。

二面

最后知道面试官是一个另一个组的老大，花名很独特：东厂

三面

HR面

HR面是提前约的视频面，面试过程半小时左右，主要是聊了聊了一些规划以及对安全的看法什么的，其中有几个让我印象比较深刻的问题：1.实习的时候我看到你还投了阿里这边的非安全岗位，当时是怎么考虑的呢？后来HR告诉我在这里可能看出我至少在当时职业规划还不是很明确，还好我回答的还算不错，巧妙化解了这个问题 2.平时都通过什么进行学习，在安全领域有什么比较崇拜的人？正好我一直关注的大佬都在阿里云，HR也很兴奋，跟我说正好你说的都在这里，开心~ 有什么 3.还有就是问offer情况，问那些这些公司的对比

总裁面

HR面完一个月在正式出结果之前，忽然通知要加一个总裁面，提前去视频会议室看了一下，居然真的是阿里云安全总裁肖力，心里慌得一批，还好最好肖老板因为云栖大会临时换了人，还是一个安全团队的老大：木瓜。面试过程整体比较难，具体细节记得不是很清楚了，除了项目以外，有一些大方向上的问题，比如安全趋势了解、区块链的了解的等等，其次还有一些传统安全相关的了解，问挖洞实践、安全竞赛实践等。

惊险通过，开心得不得了！(面试持续两个月，8.1开始面试，9.28才收到意向书，然而我还是阿里云安全最早的意向书)

美团安全部

一面

面的自我感觉还可以，但是直接凉了，挺迷茫的

腾讯安全部

一面

然后是数据库相关的问题，首先是问有两张表如何进行进行合并还有就是一个topk问题，我回答了堆排，利用大根堆的方式，但是他问能不能用小根堆，我也答了一种取负值然后进小根堆的方式，他说这个和大根堆有什么区别吗？让我看能不能快排类似的思想另外一道题目是map reduce的比较简单，分布在多台主机上的多个文件，如何根据找出topk个数据

总体来说面试难度不难，但是面试体验很差，面试官态度一直就不是很好，而且每道题必须要我想出和他一样的想法，那个topK大根堆、小根堆、快排效率上有什么区别吗，非要按照他的那个快排，感觉对腾讯的好感-1

二面

其他的问题回答的都还比较顺利，只有一个问题没有回答的很好，一道安全场景题：怎么去识别非正常登陆，例如撞库行为，这个问题后来发现阿里云的安全团队也有做过类似的事情，看来是一个比较关键的问题

三面

和面试官聊的还不错，但是因为在深圳所以拒绝了

京东金融推荐算法

一面

在一个酒店里的面试，形式和360类似，但是每天只面一场，面试的部门倾向于金融推荐类，面试官人很好，问的问题最后都会耐心解答最优方法，整体面试感觉真的很nice！下面是面到的一些问题：对于特别大的离散特征如id特征怎么进行使用？直接one-hot就有向量维度过高的问题 1.使用PCA、LDA进行降维，这种由于向量过于稀疏，不太能使用 2.embedding 是一个高维稀疏向量降维的最佳方法面试官追问，你说的这个embedding是随机初始化吧？能不能进行考虑一下怎么进行一下预训练？其实可以通过对利用各个id的前后的点击情况做类似Word2vec的预训练另一个比较核心的问题是模型正负样本比例不均衡的时候用什么指标？在进行过采样后什么时候可以直接利用模型结果？什么时候需要重新进行换算？正负样本不均匀的时候最好使用的指标当然是AUC，也可以采用精确率、召回率综合考量对于排序等只关注先后顺序的任务，可以直接使用预测结果，而对一些带阈值的分类问题，就需要对概率进行重新转化一下

二面

整个面试挺奇怪的，面试官问的问题基本上全部都会打出来了，但是还是被挂掉了，不知道是什么操作

360安全研究院

一共面了3面，具体面了什么都忘了，只记得面的很好，但是过了一个月了，还是没有消息，不知道是不是凉了。。。

互联网秋招就这样结束了，剩下这段时间就是专心做毕设和尝试在找找国企。

加密恶意流量检测论文1——《Identifying Encrypted Malware Traffic with Contextual Flow Data》

发表于 2019-07-15 更新于 2021-02-19 阅读次数： Valine：
本文字数： 1.5k 阅读时长 ≈ 1 分钟

论文：《Identifying Encrypted Malware Traffic with Contextual Flow Data》

核心点：

1.传统的流量特征提取方式一般聚焦在数据包大小和时间有关的参数上；本文拓充了特征提取范围，运用好到了完整的TLS我输数据包、同TLS握手数据包同一来源的DNS数据流和5分钟窗口内的HTTP数据流(后两者被称为contextual flow)

contextual flow：同TLS握手数据包同一来源的DNS数据流和5分钟窗口内的HTTP数据流

contextual flow特征分析角度

1.DNS流

主要分析从DNS服务器中返回带有一个地址的响应以及和这个地址相关联的TLL值。

2.HTTP流

主要分析HTTP header中的各种属性。

3.TLS流

握手包中提供的信息。

特征来源

1.TLS流

TLS流在交互之初是不加密的，因为其需要和远程服务器进行握手。我们可以观测到的未加密TLS元数据包括clientHello和clientKeyExchange。从这些包的信息中，我们可以推断出客户端使用的TLS库等信息。从这些信息中，我们可以发现，良性流量的行为轨迹与恶意流量是十分不同的。

客户端方面

Offered Ciphersuites:恶意流量更喜欢在clientHello中提供0x0004(TLS_RSA_WITH_RC4_128_MD5)套件，而良性流量则更多提供0x002f(TLS_RSA_WITH_AES_128_CBC_SHA)套件

Advertised TLS Extensions:大多数TLS流量提供0x000d(signature_algorithms)，但是良性流量会使用以下很少在恶意流量中见到的参数：0x0005 (status request)、0x3374 (next protocol negotiation)、0xff01 (renegotiation info

客户端公钥：良性流量往往选择256-bit的椭圆曲线密码公钥，而恶意流量往往选择2048-bit的RSA密码公钥。

     **服务端方面**

我们能够从serverHello流中得到服务端选择的Offered Ciphersuites和Advertised TLS Extensions信息。

证书链长度：在certificate流中，我们能够得到服务端的证书链，长度为1的证书链中70%都来自恶意流量的签名，0.1%来自良性流量的自签名

2.DNS流

恶意软件往往使用域名生成算法来随机生成域名（DGA），这是一个明显区别于普通流量的行为。

3.HTTP流

请求报头：良性流量最常用的属性为User-Agent，Accept-Encoding和Accept-Language。

响应报头：恶意流量最常用的属性为Server、Set-Cookie和Location；良性流量最常用的属性为Connection、Expires和Last-Modified

属性观察值：

Content-Type：良性最常用的为image／\,恶意流量最常用的是text／\

MIME:恶意流量常常为text／html；charset=UTF-8以及text／html；charset=utf-8

User-Agent：恶意流量常常为Opera/9.50(WindowsNT6.0;U;en)、Mozilla／5.0或Mozilla／4.0；而良性流量通常为Windows或OS X版本的Mozilla／5.0。

实验效果

虽然检测准确率是99.9%,但是由于样本极度不均衡，因此准确率并不具有很大的参考意义。而再看上表中的检出率最高的也只有83%，因此效果并不理想。

深度学习——transformer XL

发表于 2019-06-25 更新于 2021-02-19 阅读次数： Valine：
本文字数： 1.7k 阅读时长 ≈ 2 分钟

transformer XL主要用来解决Transformer对于长文档NLP任务不够友好的问题。

原始的Transformer

原始Transformer存在的缺陷：

1.算法无法建模超过固定长度的依赖关系。

2.被分割的句子通常不考虑句子边界，导致上下文碎片化

在给定无限内存和计算资源的情况下，Trnasformer为了将任意长度的上下文融入模型，可以无条件的处理整个上下文片段，但在实际情况下由于资源的限制，这显然是行不通的。

在实际使用中一种常见的近似方法为将整个语料库分割可管理大小的更短的片段(这就是多头)，只在每个片段中训练模型，忽略其他段，我们称之为原始Transformer(vanilla model)。

在评估过程中，原始Transformer模型在每个步骤消耗与训练期间相同长度的segment，但在最后一个位置只预测一次。然后，在下一步中，这个segment只向右移动一个位置，新的segment必须从头开始开始处理，虽然解决了利用较长的上下文的问题和上下文碎片化的问题，但是评估的资源消耗过大(时间、计算)

Transformer XL

Transformer XL优势：

可以在不破坏时间一致性的情况下学习固定长度以外的依赖

核心改进：

1.segment-level 的递归机制—>解决固定长度上下文局限

2.新的位置编码

实验条件下效果对比原始transformer效果提升情况：

1.在长序列和短序列都获得更好的性能

2.在长依赖上的提升十分明显

3.在速度上比原始的Transformer快了1800倍

Segment-level的递归机制

在训练过程中，对上一个 segment 计算的隐藏状态序列进行修复，并在模型处理下一个新的 segment 时将其缓存为可重用的扩展上下文。种递归机制应用于整个语料库的每两个连续的 segment，它本质上是在隐藏状态中创建一个 segment-level 的递归。因此，所使用的有效上下文可以远远超出两个 segments。

该方式除了实现超长的上下文和解决碎片问题外，这种递归方案的另一个好处是显著加快了评估速度。

相对位置编码

如果直接使用Segment-level recurrence是行不通的，因为当我们重用前面的段时，位置编码是不一致的。例如：考虑一个具有上下文位置[0,1,2,3]的旧段。当处理一个新的段时，我们将两个段合并，得到位置[0,1,2,3,0,1,2,3]，其中每个位置id的语义在整个序列中是不连贯的。

为此Transformer XL提出一种新的相当位置编码使递归成为可能。与其他相对位置编码方案不同，我们的公式使用具有learnable transformations的固定嵌入，而不是earnable embeddings，因此在测试时更适用于较长的序列。

循环机制引入了新的挑战——原始位置编码将每个段分开处理，因此，来自不同段的表征会具有相同的位置编码。例如，第一和第二段的第一个表征将具有相同的编码，虽然它们的位置和重要性并不相同（比如第一个段中的第一个表征可能重要性低一些）。这种混淆可能会错误地影响网络。

针对此问题，论文提出了一种新的位置编码方式。这种位置编码是每个注意力模块的一部分。它不会仅在第一层之前编码位置，而且会基于表征之间的相对距离而非绝对位置进行编码。从技术上讲，它对注意力头分数（Attention Head’s Score）的计算方式不再是简单的乘法（Qi⋅Kj），而是包括四个部分：

内容权重——没有添加原始位置编码的原始分数。
相对于当前内容的位置偏差（Qi）。该项使用正弦类函数来计算表征之间的相对距离（例如 i-j），用以替代当前表征的绝对位置。
可学习的全局内容偏差——该模型添加了一个可学习的向量，用于调整其他表征内容（Kj）的重要性。
可学习的全局偏差——另一个可学习向量，仅根据表征之间的距离调整重要性（例如，最后一个词可能比前一段中的词更重要）。

https://www.tuicool.com/articles/iQjEF3Y

深度学习——XLNet

发表于 2019-06-25 更新于 2021-02-19 阅读次数： Valine：
本文字数： 2.9k 阅读时长 ≈ 3 分钟

2019年6月，Google最新推出XLNet在20个任务中超越了BERT，并且在18个任务上都取得了当前最佳效果。本文主要来探究XLNet究竟在Bert的基础上做了哪些改进才完成这么大的进化呢？

Bert打开了NLP领域两阶段模式的大门

两阶段模式：

1.预训练

2.FineTuning

XLNet引入了自回归语言模型和自编码语言模型的提法，是一个很好的思维框架

自回归语言模型Autoregressive LM

从左到右或从右到左的预测当前词，这种类型的LM被称为自回归语言模型。

典型模型：GPT系列、EMLo(虽然表面上看起来做了两个方向，但是本质上是分别于两个方向的自回归语言模型，然后将隐节点状态拼接到一起，来实现双向语言模型，仍是自回归语言模型)

缺点：只能利用上文或者下文的信息(虽然ELMo利用了上文和瞎问的信息，但是因为只是简单地隐节点状态拼接，效果差强人意)

优点：对于下游任务是文本生成NLP类(机器翻译、文本摘要)等，在实际内容生成的时候，就是从左到右的，自回归语言模型天然匹配这个过程。

自编码语言模型Autoencoder LM

Bert通过随机Mask掉一部分单词，然后预训练过程根据上下文单词来预测这些被Mask掉的单词，这是经典的Denoising Autoencoder （DAE）思路，那些被Mask掉的单词就是在输入侧加入的所谓噪音,类似于Bert的这种训练预训练模式被称为DAE LM

典型模型：Bert

优点：能利用上下文的信息

缺点：1.对于文本生成类NLP任务效果不好（因为文本生成类任务本身就是单向的任务）。

2.第一个预训练阶段因为采取引入 [Mask] 标记来 Mask 掉部分单词的训练模式，而 Fine-tuning 阶段是看不到这种被强行加入的 Mask 标记的，所以两个阶段存在使用模式不一致的情形，这可能会带来一定的性能损失

3.在预训练截断，Bert假设句子中的多个单词被Mask掉的单词之间没有任何联系、条件独立，这显然是不一定成立的

XLNet

Bert的主要改进在下面的三个部分：

1.在自回归模型上引入了双向语言模型

2.引入了Transformer-XL的主要思路：相对位置编码以及分段RNN机制(长文档效果提升核心因素)

3.加大预训练使用的数据集

XLNet主要针对Bert中第二个缺陷，

在自回归语言模型中引入双向模型

为解决Mask标记两阶段不一致的问题，XLNet打算采用在自回归语言模型中引入双向语言模型来进行解决。目标为看上去仍然是从左向右的输入和预测模式，但是其实内部已经引入了当前单词的下文信息。

解决方式：

首先仍然采用双阶段模式，第一阶段为语言模型预训练，第二阶段为任务数据Fine-tuning。它主要改动的是第一截断——语言模型预训练截断，希望不再采用Bert那种带Mask标记的DAE LM模式，而是采用自回归语言模型，看上去是个标准的从左向右过程，Fine-tuning 当然也是这个过程，于是两个环节就统一起来。

MLNet解决该问题的核心思路为：在预训练阶段，引入Permutation Language Model (时序语言模型)的训练目标。

就是说，比如包含单词 Ti 的当前输入的句子 X ，由顺序的几个单词构成，比如 x1,x2,x3,x4 四个单词顺序构成。我们假设，其中，要预测的单词 Ti 是 x3 ，位置在 Position 3 ，要想让它能够在上文 Context_before 中，也就是 Position 1 或者 Position 2 的位置看到 Position 4 的单词 x4 。

可以这么做：假设我们固定住 x3 所在位置，就是它仍然在 Position 3 ，之后随机排列组合句子中的4个单词，在随机排列组合后的各种可能里，再选择一部分作为模型预训练的输入 X 。比如随机排列组合后，抽取出 x4,x2，x3,x1 这一个排列组合作为模型的输入 X 。于是，x3 就能同时看到上文 x2 ，以及下文 x4 的内容了,这就是 XLNet 的基本思想

具体实现：

XLNet 采取了 Attention 掩码的机制（一个掩码矩阵），你可以理解为，当前的输入句子是 X ，要预测的单词 Ti 是第 i 个单词，前面1到 i-1 个单词，在输入部分观察，并没发生变化，该是谁还是谁。但是在 Transformer 内部，通过 Attention 掩码，从 X 的输入单词里面，也就是 Ti 的上文和下文单词中，随机选择 i-1 个，放到 Ti 的上文位置中，把其它单词的输入通过 Attention 掩码隐藏掉，于是就能够达成我们期望的目标（当然这个所谓放到 Ti 的上文位置，只是一种形象的说法，其实在内部，就是通过 Attention Mask ，把其它没有被选到的单词 Mask 掉，不让它们在预测单词 Ti 的时候发生作用，如此而已。看着就类似于把这些被选中的单词放到了上文 Context_before 的位置,论文中采用双流自注意力机制来进行具体实现

双流自注意力机制

1.内容注意力标准的transfomer计算过程

2.Query流自注意力这里并不是很懂

XLNet效果好的核心因素：

1.在自回归模式下引入和双向语言模型。

2.引入了Transformer-XL的主要思路：相对位置编码以及分段RNN机制(长文档效果提升核心因素)

3.加大预训练使用的数据集

XLNet和Bert对比

1.预训练过程不同

尽管看上去，XLNet在预训练机制引入的Permutation Language Model这种新的预训练目标，和Bert采用Mask标记这种方式，有很大不同。其实你深入思考一下，会发现，两者本质是类似的。区别主要在于：Bert是直接在输入端显示地通过引入Mask标记，在输入侧隐藏掉一部分单词，让这些单词在预测的时候不发挥作用，要求利用上下文中其它单词去预测某个被Mask掉的单词；而XLNet则抛弃掉输入侧的Mask标记，通过Attention Mask机制，在Transformer内部随机Mask掉一部分单词（这个被Mask掉的单词比例跟当前单词在句子中的位置有关系，位置越靠前，被Mask掉的比例越高，位置越靠后，被Mask掉的比例越低），让这些被Mask掉的单词在预测某个单词的时候不发生作用。所以，本质上两者并没什么太大的不同，只是Mask的位置，Bert更表面化一些，XLNet则把这个过程隐藏在了Transformer内部而已。这样，就可以抛掉表面的[Mask]标记，解决它所说的预训练里带有[Mask]标记导致的和Fine-tuning过程不一致的问题

2.XLNet坚持了自编码LM的从左到右的方式，因此XLNet在文本生成类任务上效果要比Bert好

3.XLNet引入了Transfomer XL的机制，因此对于长文本效果比Bert更好

XLNet在NLP各个领域中效果情况

1.对于阅读理解任务，效果有极大幅度的提升

2.长文档类任务，性能大幅度提升

3.综合型NLP任务，有所提升

4.文本分类和信息检索任务，有所提升，但幅度不大

总结：主要是长文档任务提升比较明显，其他类型的任务提升不大

机试——数组中的逆序对

发表于 2019-06-23 更新于 2021-02-19 阅读次数： Valine：
本文字数： 363 阅读时长 ≈ 1 分钟

题目：在数组中的两个数字，如果前面一个数字大于后面的数字，则这两个数字组成一个逆序对。输入一个数组,求出这个数组中的逆序对的总数P。并将P对1000000007取模的结果输出。即输出P%1000000007

实例:

输入：1,2,3,4,5,6,7,0

输出：7

https://blog.csdn.net/lzq20115395/article/details/79554591

解法一：暴力冒泡

这种方法比较简单，但是时间复杂度为O(n^2),这里不做详细阐述

解法二：归并法

完全按照归并排序的方式来进行，只是附加上一个全局变量，来记录。

global count
count = 0
def InversePairs(data):
    
    def core(data):
        # write code here
        if len(data) <= 1:
            return data
        num = int(len(data) / 2)

        left = core(data[:num])
        right =core(data[num:])
        return Merge(left, right)
    core(data)
    
    return count

#合并各个子数组
def Merge(left, right):
        global count
        l1 = len(left)-1
        l2 = len(right)-1
        
        res = []
        num = 0
        while l1>=0 and l2>=0:
            if left[l1]<=right[l2]:
                res = [right[l2]]+res
                l2-=1
            else:
                res  = [left[l1]]+res
                count += l2+1
                l1-=1
        while l1>=0:
            res  = [left[l1]]+res
            l1-=1
        while l2>=0:
            res = [right[l2]]+res
            l2-=1
        
        return res

解法3：

先将原来数组进行排序，然后从排完序的数据中去取出最小的，他在原数组中的位置能表示有多少比他大的数在他前面，每取出一个在原数组中删除该元素，保证后面去除的元素在原数组中是最小的，这样

机试——从1到n正数中1出现的个数

发表于 2019-06-23 更新于 2021-02-19 阅读次数： Valine：
本文字数： 333 阅读时长 ≈ 1 分钟

https://blog.csdn.net/yi_afly/article/details/52012593

题目:b求出1~13的整数中1出现的次数,并算出100~1300的整数中1出现的次数？为此他特别数了一下1~13中包含1的数字有1、10、11、12、13因此共出现6次,但是对于后面问题他就没辙了。ACMer希望你们帮帮他,并把问题更加普遍化,可以很快的求出任意非负整数区间中1出现的次数（从1 到 n 中1出现的次数）。

总结各个位上面1出现的次数，我们可以发现如下规律:

若weight为0，则1出现次数为round*base
若weight为1，则1出现次数为round*base+former+1
若weight大于1，则1出现次数为rount*base+base

def NumberOf1Between1AndN_Solution(self, n):
        # write code here
        if n<1:
            return 0
        
        count  = 0
        base = 1     #用来记录每个round中1出现的次数，weight为个位时，base为1，weight为十位时，base为10
        rou = n
        
        while rou>0:
            weight = rou%10    #知识当前最低位的值，依次获得个位数、十位数、百位数
            rou//=10            #获得最低位前面的全部位，也就是round值
            count+=rou*base    #无论weight为任何数，当前位为1的个数都至少为rou*base
            
            #如果weight为1，那么当前位为1的个数前一位的值+1
            if weight==1:
                count += (n%base)+1
            elif weight>1:
                count += base
            
            base*=10
        return count

机试——二叉搜索树转双向链表

发表于 2019-06-23 更新于 2021-02-19 阅读次数： Valine：
本文字数： 106 阅读时长 ≈ 1 分钟

题目：输入一棵二叉搜索树，将该二叉搜索树转换成一个排序的双向链表。要求不能创建任何新的结点，只能调整树中结点指针的指向

设计到二叉搜索树基本上绕不过的思路就是中序遍历，这道题的思路依然是在中序遍历的基础上进行的改进

class Solution:
	def __init__():
		self.listHead = None   #用来标记双向链表的起始节点
    self.listtail = None   #用来标记当前正在调整的节点
  def Convert(pRoot):
    if pRoot==None:
      return 
    
    self.Convert(pRoot.left)
    
    if self.listHead==None:  
      self.listHead = pRoot   #第一个节点时，直接将两个指针指向这两个节点
      self.listTail = pRoot
    else:
      self.listTail.right = pRoot   #核心：后面的节点,pRoot相当于下一个节点 ，可以从栈的角度进行想象
      pRoot.left = self.listTail
      self.listTail = pRoot
    
    self.Convert(pRoot.right)
    
    return self.listHead