安全面试、笔试、学习知识点大杂烩2

凌晨四点的代码

已于 2022-03-08 12:34:29 修改

阅读量315

点赞数

分类专栏：面试文章标签：学习安全面试网络安全

于 2022-03-08 12:33:56 首次发布

本文链接：https://blog.csdn.net/qq_44704184/article/details/123333246

版权

面试专栏收录该内容

3 篇文章 1 订阅

订阅专栏

域名的解析

使用DNS协议根据域名查询ip两种方式：递归查询和迭代查询
注意：
一、主机向本地域名服务器的查询一般都是采用递归查询。所谓递归查询就是：如果主机所询问的本地域名服务器不知道被查询的域名的IP地址，那么本地域名服务器就以DNS客户的身份，向其它根域名服务器继续发出查询请求报文(即替主机继续查询)，而不是让主机自己进行下一步查询。因此，递归查询返回的查询结果或者是所要查询的IP地址，或者是报错，表示无法查询到所需的IP地址。
在这里插入图片描述
二、本地域名服务器向根域名服务器的查询的迭代查询。迭代查询的特点：当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出所要查询的IP地址，要么告诉本地服务器：“你下一步应当向哪一个域名服务器进行查询”。然后让本地服务器进行后续的查询。根域名服务器通常是把自己知道的顶级域名服务器的IP地址告诉本地域名服务器，让本地域名服务器再向顶级域名服务器查询。顶级域名服务器在收到本地域名服务器的查询请求后，要么给出所要查询的IP地址，要么告诉本地服务器下一步应当向哪一个权限域名服务器进行查询。最后，知道了所要解析的IP地址或报错，然后把这个结果返回给发起查询的主机。

栈帧(stack frame)

函数每次被调用时，要在调用栈(call stack)上占用一段空间，
在这段空间上保存调用者栈帧的基址(ebp)、本函数的局部变量、调用其他函数时的返回地址，
并在需要时保存调用者使用的寄存器值，
被调函数结束后esp上移表示释放这段空间，然后回到调用者的占用的空间与代码位置继续执行，
函数运行阶段在调用栈上占用的这段空间就叫做栈帧，是编译原理运行时空间组织中活动记录（activation record）的一种实现

栈帧主要通过 ebp、esp 两个寄存器维护，ebp 始终指向栈底，esp 始终指向栈顶

每个函数被调用时执行下面两条命令

pushl	%ebp			; ebp入栈，保存调用者的栈帧基址，以便返回
movl	%esp, %ebp		; 将当前 esp 的位置作为当前栈帧的基址

在这里插入图片描述

注意几乎所有的机器与操作系统上栈都是由高地址向低地址生长的

CSP

1.CSP是什么
CSP指的是内容安全策略，为了缓解很大一部分潜在的跨站脚本问题，浏览器的扩展程序系统引入了内容安全策略（CSP）的一般概念。这将引入一些相当严格的策略，会使扩展程序在默认情况下更加安全，开发者可以创建并强制应用一些规则，管理网站允许加载的内容。简单来说，就是我们能够规定，我们的网站只接受我们指定的请求资源。
2. CSP的意义
防XSS等攻击的利器。CSP 的实质就是白名单制度，开发者明确告诉客户端，哪些外部资源可以加载和执行，等同于提供白名单。它的实现和执行全部由浏览器完成，开发者只需提供配置。CSP 大大增强了网页的安全性。攻击者即使发现了漏洞，也没法注入脚本，除非还控制了一台列入了白名单的可信主机。
3.CSP的分类
（1）Content-Security-Policy
配置好并启用后，不符合 CSP 的外部资源就会被阻止加载。
（2）Content-Security-Policy-Report-Only
表示不执行限制选项，只是记录违反限制的行为。它必须与report-uri选项配合使用。
4.CSP的使用
（1）在HTTP Header上使用（首选）

"Content-Security-Policy:" 策略
"Content-Security-Policy-Report-Only:" 策略

（2）在HTML上使用

<meta http-equiv="content-security-policy" content="策略">
<meta http-equiv="content-security-policy-report-only" content="策略">

Meta 标签与 HTTP 头只是形式不同而作用是一致的，如果 HTTP 头与 Meta 定义同时存在，则优先采用 HTTP 中的定义。
如果用户浏览器已经为当前文档执行了一个 CSP 的策略，则会跳过 Meta 的定义。如果 META 标签缺少 content 属性也同样会跳过。

5.策略应该怎么写

// 限制所有的外部资源，都只能从当前域名加载
Content-Security-Policy: default-src 'self'

// default-src 是 CSP 指令，多个指令之间用英文分号分割；多个指令值用英文空格分割
Content-Security-Policy: default-src https://host1.com https://host2.com; frame-src 'none'; object-src 'none'  

// 错误写法，第二个指令将会被忽略
Content-Security-Policy: script-src https://host1.com; script-src https://host2.com

// 正确写法如下
Content-Security-Policy: script-src https://host1.com https://host2.com

// 通过report-uri指令指示浏览器发送JSON格式的拦截报告到某个地址
Content-Security-Policy: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

6、常用的CSP指令
在这里插入图片描述
7、其他的CSP指令

8、CSP指令值

同源策略

1、定义
同源策略（Same origin policy）是一种约定，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，则浏览器的正常功能可能都会受到影响。可以说Web是构建在同源策略基础之上的，浏览器只是针对同源策略的一种实现。
如果两个页面（接口）的协议、域名、端口号都相同，我们认为他们具有相同的源
例在这里插入图片描述

2、源的更改
满足某些限制条件的情况下，页面是可以修改它的源。脚本可以将 document.domain 的值设置为其当前域或其当前域的父域。如果将其设置为其当前域的父域，则这个较短的父域将用于后续源检查。

例如：假设 http://store.company.com/dir/other.html 文档中的一个脚本执行以下语句document.domain = “company.com”;这条语句执行之后，页面将会成功地通过与 http://company.com/dir/page.html 的同源检测（假设http://company.com/dir/page.html 将其 document.domain 设置为“company.com”，以表明它希望允许这样做）。然而，company.com 不能设置 document.domain 为 othercompany.com，因为它不是 company.com 的父域。

端口号是由浏览器另行检查的。任何对document.domain的赋值操作，包括 document.domain = document.domain 都会导致端口号被重写为 null 。因此 company.com:8080 不能仅通过设置 document.domain = “company.com” 来与company.com 通信。必须在他们双方中都进行赋值，以确保端口号都为 null 。

3、跨源网络访问
同源策略控制不同源之间的交互，例如在使用XMLHttpRequest 或标签时则会受到同源策略的约束。这些交互通常分为三类：

跨域写操作（Cross-origin writes）一般是被允许的。例如链接（links），重定向以及表单提交。特定少数的HTTP请求需要添加 preflight。
跨域资源嵌入（Cross-origin embedding）一般是被允许。
跨域读操作（Cross-origin reads）一般是不被允许的，但常可以通过内嵌资源来巧妙的进行读取访问。例如，你可以读取嵌入图片的高度和宽度，调用内嵌脚本的方法，或availability of an embedded resource.

4、如何允许跨源访问
可以使用 CORS 来允许跨源访问。CORS 是 HTTP 的一部分，它允许服务端来指定哪些主机可以从这个服务端加载资源。

5、如何阻止跨源访问
阻止跨域写操作，只要检测请求中的一个不可推测的标记(CSRF token)即可，这个标记被称为 Cross-Site Request Forgery (CSRF) 标记。你必须使用这个标记来阻止页面的跨站读操作。
阻止资源的跨站读取，需要保证该资源是不可嵌入的。阻止嵌入行为是必须的，因为嵌入资源通常向其暴露信息。
阻止跨站嵌入，需要确保你的资源不能通过以上列出的可嵌入资源格式使用。浏览器可能不会遵守 Content-Type 头部定义的类型。例如，如果您在HTML文档中指定

Web代码审计

web安全重点就三个词——“输入”，“输出”，“数据流”。

1、逆向追踪/回溯变量—检查敏感函数的参数，判断参数可控？是否有过滤？

                                搜索响应的敏感关键字，定向挖掘，高效、高质量

根据敏感关键字回溯参数传递过程

根据敏感函数来逆向追踪参数的传递过程，是目前使用得最多的一种方式，因为大多数漏洞是由于函数的使用不当造成的。另外非函数使用不当的漏洞，如 SQL 注入，也有一些特征，比如 Select、 Insert 等，再结合 From 和 Where 等关键字，我们就可以判断这是否是一条 SQL 语句，通过对字符串的识别分析，就能判断这个 SQL 语句里面的参数有没有使用单引号过滤，或者根据我们的经验来判断。

像 HTTP 头里面的 HTTP_ CLIENT_ IP 和 HTTP_ X_ FORWORDFOR 等获取到的 IP 地址经常没有安全过滤就直接拼接到 SQL 语句中，并且由于它们是在$_ SERVER 变量中不受 GPC 的影响，那我们就可以去查找 HTTP_ CLIENT_ IP 和 HTTP_ X_ FORWORDFOR 关键字来快速寻找漏洞。

2、正向追踪/跟踪变量—找到哪些文件在接收外部传入的参数，跟踪变量的传递过程，观察是否有高危函数

3、直接挖掘功能点漏洞—根据自身经验判断

4、通读全文—index文件，了解程序架构

                  函数集文件，通常名为functions，common 等

                  配置文件，config

                  安全过滤文件，filter safe,check

一般实战流程：
1、浏览网站目录结构
2、看主页index.php—可以一边看代码，一边看网页效果，构建相应的情景图
3、看注释，了解网站的大概规模
4、看引用了哪些操作文件
5、点击网页用户输入的位置，看网页如何跳转，找到相关的文件，看是如何操作的
6、利用正则匹配，每个网页都能找到用户控制的变量

Java代码审计-Checklist
通常把代码审计的方向分为业务层安全问题、代码实现和服务架构安全问题,。

业务层安全常见问题
业务层的安全问题集中在业务逻辑和越权问题上，我们在代码审计的过程中尽可能的去理解系统的业务流程以便于发现隐藏在业务中的安全问题。

1.1 业务层中常见的安全问题Checklist

1.用户登陆、用户注册、找回密码等功能中密码信息未采用加密算法。

2.用户登陆、用户注册、找回密码等功能中未采用验证码或验证码未做安全刷新(未刷新Session中验证码的值)导致的撞库、密码爆破漏洞。

3.找回密码逻辑问题(如:可直接跳过验证逻辑直接发包修改)。

4.手机、邮箱验证、找回密码等涉及到动态验证码等功能未限制验证码失败次数、验证码有效期、验证码长度过短导致的验证码爆破问题。

5.充值、付款等功能调用了第三方支付系统未正确校验接口(如:1分钱买IPhone X)。

6.后端采用了ORM框架更新操作时因处理不当导致可以更新用户表任意字段(如:用户注册、用户个人资料修改时可以直接创建管理员账号或其他越权修改操作)。

7.后端采用了ORM框架查询数据时因处理不当导致可以接收任何参数导致的越权查询、敏感信息查询等安全问题。

8.用户中心转账、修改个人资料、密码、退出登陆等功能未采用验证码或Token机制导致存在CSRF漏洞。

9.后端服务过于信任前端，重要的参数和业务逻辑只做了前端验证(如:文件上传功能的文件类型只在JS中验证、后端不从Session中获取用户ID、用户名而是直接接收客户端请求的参数导致的越权问题)。

10.用户身份信息认证逻辑问题(如:后台系统自动登陆时直接读取Cookie中的用户名、用户权限不做验证)。

11.重要接口采用ID自增、ID可预测并且云端未验证参数有效性导致的越权访问、信息泄漏问题(如:任意用户订单越权访问)。

12.条件竞争问题，某些关键业务(如:用户转账)不支持并发、分布式部署时不支持锁的操作等。

13.重要接口未限制请求频率，导致短信、邮件、电话、私信等信息轰炸。

14.敏感信息未保护，如Cookie中直接存储用户密码等重要信息。

15.弱加密算法、弱密钥，如勿把Base64当成数据加密方式、重要算法密钥采用弱口令如123456。

16.后端无异常处理机制、未自定义50X错误页面,服务器异常导致敏感信息泄漏(如:数据库信息、网站绝对路径等)。

17.使用DWR框架开发时前后端不分漏洞(如:DWR直接调用数据库信息把用户登陆逻辑直接放到了前端来做)。

代码实现常见问题
代码审计的核心是寻找代码中程序实现的安全问题，通常我们会把代码审计的重心放在SQL注入、文件上传、命令执行、任意文件读写等直接威胁到服务器安全的漏洞上，因为这一类的漏洞杀伤力极大也是最为致命的。
2.1 代码实现中常见的安全问题Checklist

1.任意文件读写(文件上传、文件下载)、文件遍历、文件删除、文件重命名等漏洞

  2.SQL注入漏洞

  3.XXE(XML实体注入攻击)

  4.表达式执行(SpEL、OGNL、MVEL2、EL等)

  5.系统命令执行漏洞(ProcessBuilder)

  6.反序列化攻击(ObjectInputStream、JSON、XML等)

  7.Java反射攻击

  8.SSRF攻击

_security_cookie

__security_cookie ，是编译器的安全检查机制。
从广义上讲，它应该是一种保护栈的机制，提供这种保护的，是程序本身，编译进程序本身的
代码提供的，而不是系统中某个运行在黑暗角落中的线程。

原理：
ebp中存放着栈的一个地址(栈其实也是一片内存，ebp只是指向其中一个对当前函数内部比较
重要的地址，其实是相当重要)，栈的其它位置都是通过这个ebp来寻址的。
例：我们给函数的第一个形参的地址，就是ebp+8,第二个就是ebp+c,我们定义的局部变量的地址，第一个局部变量是ebp-4,第二局部变量的地址就是ebp-8，依此类推。
当call运行完毕，当前的堆栈结构已经给出，如果在函数里调用strcpy()往局部变量1 里考入东西，对长度没有进行检测，那么ebp-4,ebp,ebp+4,还有后面的地址，其所在的内容都会被覆盖掉。这里溢出就发生了，我们控制住了ret的返回地址，ret指令会从栈顶弹出元素给IP，也就是下一条要执行的指令的地址

加入"security cookie"后的call指令运行完以后，堆栈的变化。
在ebp上面，第一个局部变量的下面，填入的一个新的值，这个值就是所谓的"security cookie"
.按照前面说的溢出过程，ebp- 4的内容被覆盖掉，即security cookie的值被修改，在函数返回，即执行ret指令前，会call另一个函数，这个函数就是用来对比 ebp-4的值和当时push到栈中的值是不是一样，不一样的话，就说明溢出了，然后进程被终止。

这个security cookie是如何计算出来的？
其本身是保存在全局变量里的，其创建是编译器在编译阶段就创建的，然后写入到.data段里
但这个值又是变化的，windows装载器完成必要的前期准备工作后(如创建进程，为栈分配内存，等待)
把 EIP（它可存储着我们cpu要读取指令的地址）设置为PE里的代码入口处，第一个执行的指令就是一个call调用，这个call调用就是用来初始化这个cookie值的

是什么时候填入到栈里面的？
（在函数入口处，保存信息时。）
过去的不带这种保护的代码，在函数入口处一般是这样的：
push ebp
mov ebp,esp
sub ebp,n ;这条指令可能不同，不过多数情况下都是这样来为局部变量分配空间的。然后，后面就开始执行我们的代码了，加入这种保护后，会在sub ebp,n后面，加入一条像这样的指令：
mov dword ptr [ebp-4],XXX
XXX就是security cookie的值，这个值保存在全局变量里，通过RVA＋PE头地址，实际上也可以说成是绝对地址来引用了。到这里security cookie的值就写入栈了

登录页面渗透测试思路与总结

1、扫描器扫描
在条件允许的情况下，我们可以拿在渗透测试的开始之前拿出我们的扫描器来进行扫描，目前我们最常用的就是AWVS（是一款知名的Web网络漏洞扫描工具，它通过网络爬虫测试你的网站安全，检测流行安全漏洞。）和Nessus（Nessus号称是世界上最流行的漏洞扫描程序，全世界有超过75000个组织在使用它。该工具提供完整的电脑漏洞扫描服务，并随时更新其漏洞数据库。Nessus不同于传统的漏洞扫描软件，Nessus可同时在本机或远端上遥控，进行系统的漏洞分析扫描。），Appscan
SQL注入、万能密码、'or 1=1 –、"or “a”="a等或者随便输入用户名密码验证码登录，抓包，放在记事本里，sqlmap -r跑一下，级别调高一点

2、明文传输/用户名可枚举/爆破弱口令
明文传输
可能是我们做渗透测试中，最常见的一种漏洞，实际上它并不能算得上是一种漏洞，仅仅只能说是一种不足之处而已，明文传输在网站上随处可见，除了银行网站，很有可能每一个密码都是经过特殊加密然后再进行传输的。

用户名可枚举
此漏洞存在主要是因为页面对所输入的账号密码进行的判断所回显的数据不一样，我们可以通过这点来进行用户名的枚举，然后通过枚举后的账户名来进行弱口令的爆破。防御手段的话仅需要将用户名与密码出错的回显变成一样即可，例如用户名或密码出错。

爆破弱口令
弱口令可以说是渗透测试中，最最常见，也是危害“最大”的一种漏洞，因为毫无技术性，毫无新意，但是却充满了“破坏性”，尤其是在内网环境中，弱口令更是无处不在。Web页面最常用的爆破工具为Burp，我们通常使用Nmap扫描也可能扫出其他端口存在，例如3389，SSH等。

3、关键位置扫描
目录扫描
扫描站点的目录，寻找敏感文件（目录名，探针文件，后台，robots.txt，备份文件）；
JS扫描
JS文件我们在渗透测试中也是经常用到的东西，有时候我们可以在JS文件中找到我们平时看不到的东西，例如重置密码的JS，发送短信的JS，都是有可能未授权可访问的。
JS扫描的话推荐使用JSFind（信息搜集），也会提取页面中的URL

nmap扫描

在这里插入图片描述

Windows下DLL查找顺序

LoadLibrary是加载dll库文件GetProcAddress函数则是找到函数地
DLL是一个包含可由多个程序，同时使用的代码和数据的库。

1.DLL查找路径基础

应用程序可以通过以下方式控制一个DLL的加载路径：使用全路径加载、使用DLL重定向、使用manifest文件。如果上述三种方式均未指定，系统查找DLL的顺序将按照本部分描述的顺序进行。

对于以下两种情况的DLL，系统将不会查找，而是直接加载：

a. 对于已经加载到内存中的同名DLL，系统使用已经加载的DLL，并且忽略待加载DLL的路径。（注意对某个进程而言，系统已经加载的DLL一定是唯一的存在于某个目录下。）

b. 如果该DLL存在于某个Windows版本的已知DLL列表（unkown DLL）中，系统使用已知DLL的拷贝（包括已知DLL的依赖项）。已知DLL列表可以从如下注册表项看到：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs。

这里有个比较坑的地方，对于有依赖项的DLL（即使使用全路径指定DLL位置），系统查找其所依赖DLL的方法是按照实际的模块名称来的，因此如果加载的DLL不在系统查找顺序目录下，那么动态加载该DLL（LoadLibrary）会返回一个"找不到模块"的错误。

系统使用的标准DLL查找顺序依赖于是否设置了"安全DLL查找模式"（safe DLL search mode）。"安全DLL查找模式"会将用户当前目录置于查找顺序的后边。

启用"安全DLL查找模式"时，查找顺序如下：

a. 应用程序所在目录；

b. 系统目录。GetSystemDirectory返回的目录，通常是系统盘\Windows\System32；

c. 16位系统目录。该项只是为了向前兼容的处理，可以不考虑；

d. Windows目录。GetWindowsDirectory返回的目录，通常是系统盘\Windows；

e. 当前目录。GetCurrentDirectory返回的目录；

f. 环境变量PATH中所有目录。

如果"安全DLL查找模式"被禁用，查找顺序如下：

a. 应用程序所在目录；

b. 当前目录。GetCurrentDirectory返回的目录；

c. 系统目录。GetSystemDirectory返回的目录，通常是系统盘\Windows\System32；

d. 16位系统目录。该项只是为了向前兼容的处理，可以不考虑；

e. Windows目录。GetWindowsDirectory返回的目录，通常是系统盘\Windows；

f. 环境变量PATH中所有目录。

凌晨四点的代码

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
安全面试、笔试、学习知识点大杂烩2

使用DNS协议根据域名查询ip两种方式：递归查询和迭代查询域名的解析过程注意：一、主机向本地域名服务器的查询一般都是采用递归查询。所谓递归查询就是：如果主机所询问的本地域名服务器不知道被查询的域名的IP地址，那么本地域名服务器就以DNS客户的身份，向其它根域名服务器继续发出查询请求报文(即替主机继续查询)，而不是让主机自己进行下一步查询。因此，递归查询返回的查询结果或者是所要查询的IP地址，或者是报错，表示无法查询到所需的IP地址。二、本地域名服务器向根域名服务器的查询的迭代查询。迭代查询的特点：
复制链接

扫一扫