WEB/系统安全

安全性相关的HTTP头部设置：
Strict-Transport-Security：强制使用安全连接（SSL/TLS之上的HTTPS）来连接到服务器。
X-Frame-Options：提供对于“点击劫持”的保护。
X-XSS-Protection：开启大多现代浏览器内建的对于跨站脚本攻击（XSS）的过滤功能。
X-Content-Type-Options： 防止浏览器使用MIME-sniffing来确定响应的类型，转而使用明确的content-type来确定。
Content-Security-Policy：防止受到跨站脚本攻击以及其他跨站注入攻击。
cookie属性的列表：
secure：仅在请求是通过HTTPS传输时，才传递cookie。
HttpOnly：将禁止javascript脚本获取到这个cookie，这可以用来帮助防止跨站脚本攻击。
domain：比较请求URL中服务端的域名，如果域名匹配成功，或这是其子域名，则继续检查path属性。
path：除了域名，cookie可用的URL路径也可以被指定。当域名和路径都匹配时，cookie才会随请求发送。
expires：设置持久化的cookie，当设置了它之后，cookie在指定的时间到达之前都不会过期。

CSRF：迫使用户在他们已登录的web应用中，执行一个并非他们原意的操作的攻击手段。这种攻击常常用于那些会改变用户的状态的请求，通常它们并不窃取数据，因为攻击者并不能看到响应的内容。

攻击原理：
用户C打开浏览器，访问受信任网站A，输入用户名和密码登录网站A。
在用户信息通过验证之后，网站A产生cookie信息并返回给浏览器，这时用户登录网站A成功，可以正常发送求请求到网站A。
用户未退出网站A之前，在同一浏览器中，打开一个页面访问网站B。
网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问网站A。
用户在接收到B返回的攻击性代码后，在不知情的情况下携带cookie信息，向网站A发送请求。而网站A不知道这个请求其实是B发的（误认为是用户发的），会根据用户C的cookie的信息以C的权限处理该请求，导致网站B的恶意代码被执行。

防御CSRF攻击
三种策略：验证HTTP Referer字段，在请求地址中添加token并验证，在http头中自定义属性并验证。

JSON/JSONP劫持
攻击者通过某些特定的手段，将本应该返回给用户的JSON数据进行拦截，转而将数据发送回给攻击者。
1.受攻击的网站URL返回一个JSON对象或者数组，并且返回的数据有重要的价值，也就是敏感的数据
2.受攻击的网站地址支持GET请求的响应（其实POST请求也可以做到JSON劫持，只不过需要对受害人进行诱导提及表单以发送POST请求，相比GET请求来说十分麻烦）
3.受害人的浏览器没有禁用javascript
4.受害人浏览了钓鱼/恶意网站，并且受害人在受攻击的网站中，保存在COOKIE中的身份验证信息尚未清除
5.受攻击的站点没有做相关的防御措施

钓鱼后，通过Object.prototype.__defineSetter__ 这个函数来触发攻击者自己的代码，或者是通过callback回调自己的代码

JSON/JSONP劫持属于CSRF的攻击范畴，所以解决的方法和解决CSRF的方法一样
1.验证HTTP Referer
2.请求中添加csrfToken，并在后端进行验证

基于DOM的跨站点脚本编制（XSS）
XSS（Cross Site Script）：跨站点脚本编制，指的是攻击者向合法的web页面插入恶意的脚本代码（通常是是HTML代码和JS代码），然后提交给服务器，随即服务器响应页面（被植入的恶意脚本代码），攻击者可以利用这些恶意脚本代码进行会话挟持登攻击。例如：攻击者在论坛中放一个看似安全得连接，骗取用户点击之后，盗取cookies得用户隐私信息。
XSS通常被分为：反射型和持久型
反射型：恶意代码请求的数据在服务器中呈现为未编码和未过滤。
持久性：恶意代码请求的数据被保存在服务器中，每次用户访问这个页面时，恶意代码都会被执行。
第三类基于DOM的跨站点脚本编制不依赖服务器端的内容，比如HTML页面使用了document.location、document.URL、或者document.referer等DOM元素的属性，攻击者可以利用这些属性植入恶意脚本。

XSS防范方法
代码里对用户输入的地方需要仔细检查长度和对“<”“>”“,”“'”等字符串做过滤。
任何内容写到页面之前都必须加以encode，避免不小心把html tag弄出来。
避免直接在cookie中泄露用户隐私，例如email、密码等。
如果网站不需要在浏览器对cookie进行操作，可以在set-cookie末尾加上HttpOnly来防止js代码直接获取cookie。
尽量采用post而不是get提交表单。

XXE：利用程序解析XML时加载外部实体进行攻击。
攻击原理：XML规则允许通过DTD来定义存在什么标签，拥有什么属性，包含什么元素等，而这个实体的标识符又可以访问本地或者远程内容来加载到程序。当允许引用外部实体时，而XML数据又是来自外部输入，通过构造恶意内容，就可能导致任意文件读取、系统命令执行、内网端口探测、攻击内网网站等。

XXE防范方法
1.禁止外部实体或不允许XML中含有任何自己声明的DTD。
2.不使用外部输入数据。
3.过滤掉外部输入的XML数据中的关键词，如DOCTYPE、ENTITY、SYSTEM、PUBLIC等。

基于URL的重定向
指的是web页面会采用HTTP参数来保存URL，且web页面的脚本会将请求重定向到该保存的URL上，攻击者可以将HTTP中保存的URL改为恶意站点。

客户端JS Cookie引用
cookie由服务器创建，并存储在客户端浏览器，保存用户的身份识别、session信息、甚至授权信息等。
客户端js可以操作cookie数据，
如果在客户端使用JS创建或者修改站点的cookie，那么攻击者就可以查看这些代码，然后根据逻辑修改cookie。一旦cookie中边包含重要的信息，攻击者很容易利用这些漏洞进行特权升级等。

JS劫持
许多的应用程序利用JSON作为AJAX的数据传输机制，这通常会收到JS挟持攻击。
JSON实际就是一段JS代码，通常是数组格式，
攻击者在其恶意站点的网页中通过<script>标签调用被攻击站点的JSON动态数据接口，通过JS Function Hook等技术获得这些JSON数据。

'\'\\\'\''

缓冲区溢出
return-to-libc，缓冲区溢出的变体攻击，让漏洞程序在函数返回时跳转到现存的命令执行代码，如已经载入内存的libc库中的system函数地址等来实现我们的攻击

实现原理：
当函数内的一个数组缓冲区接受用户输入的时候，一旦程序代码未对输入的长度进行合法性检查的话，缓冲区溢出便有可能触发。如下函数：
void fun(unsigned char *data)
{
    unsigned char buffer[10];
    strcpy((char*)buffer,(char*)data);//溢出点
}
当把data的数据拷贝到buffer时，超过缓冲区区域的高地址部分数据会“淹没”原本的其他栈帧数据，如果在data本身的数据内就保存了一系列的指令的二进制代码，一旦栈溢出修改了函数的返回地址，并将该地址指向这段二进制代码的起始位置，那么就形成成了基本的溢出攻击行为。

缓冲区溢出防护
1.通过操作系统使得缓冲区不可执行，从而阻止攻击者植入攻击代码。
2.强制写正确的代码的方法，使用安全的内存操作函数。
1）检查是否有使用strcpy、strcat、sprintf、vsprintf等危险函数，其数据是否有越界可能。
2）检查使用gets、fgets、getchar、fgetc、getc、read、scanf、sscanf、fscanf、vfscanf、vscanf、vsscanf、getenv等函数时，其数据是否有越界可能。
3）检查使用strncpy、strncat、snprintf等函数时，n为是否为缓冲区可接收的最大长度减1 。（snprintf在linux上内部有减1）
4）检查使用memcpy等函数时，n为要拷贝的长度，并且在拷贝之前要对n进行检查，是否小于等于缓冲区最大容量。
3.利用编译器的边界检查来实现缓冲区的保护。这个方法使得缓冲区溢出不可能出现，从而完全消除了缓冲区溢出的威胁，但是相对而言代价比较大。（由于在C语言中数组的概念和通用指针的混用，边界检查最难实现之处在于其很难确定数组的边界）
4.一种间接的方法，这个方法在程序指针失效前进行完整性检查，即通过在所有的代码指针之后放置附加字节来检验指针在被调用之前的合法性，如果检验失败，会发出报警信号和退出程序的执行。（与第3中方案边界检查相比，并不能防止所有的缓冲区溢出问题，然而其在执行的性能和兼容性上具有相当的优势）
这种方案有两点需要注意：
附加字节的定位：
附加字节的空间是在被保护的变量被分配的时候分配的，同时在被保护字节初始化过程中被初始化。这样就带来了问题，为了保持兼容性，我们不想改变被保护变量的大小，因此我们不能简单地在变量的结构定义中加入附加字。另外，对各种类型也有不同附加字节数目。
检查附加字节：
每次程序指针被引用的时候都要检查附加字节的完整性。这个也存在问题，因为“从存取器读”在编译器中没有语义，编译器更关心指针的使用，而各种的优化算法倾向于从存储器中读入变量。

数组越界（与缓存冲区溢出类似）
数组变量在定义时就已经确定了所使用的内存空间大小，因此，程序在运行过程中数组变量的索引超过了定义的内存大小，就可能非法读取或修改相邻内存的重要信息。
数组越界漏洞产生必须具备的3个条件：
1.存在数组的形式
2.存在对数组的拷贝或读取操作
3.引用数组下标，超过了数组下标的允许范围

C/C++为了提高运行效率不会自动检查数组越界，数组越界在程序编译时不会报错，从而在执行时候产生非法操作或得不到正确的结果。

检查数组越界的方法：
1.动态检测方法：在源代码中可能出现数组越界的位置进行插桩，即在程序中数组使用的地方兼容逻辑断言，在运行中检查是否存在数组越界。
2.静态检测方法：通过分析源代码来检测可能存在的安全漏洞，其主要是对源程序进行词法和语法分析，将节点挂着语法树上进行检测分析，与预先定义好的漏洞数据库进行匹配查找。

格式化字符串漏洞
存在格式化字符串漏洞的函数包括: scanf, printf, vprintf, vfprintf, sprintf, snprintf, vsprintf, vsnprintf, setproctitle, syslog等，示例如下：
#include <bits/stdc++.h>
using namespace std;
int main()
{
  char a[100];
  scanf("%s",a);
  printf(a);
  return 0;
}
如果用户输入的字符串是"%x%x%x"，则会输出内存中的数据，这是因为printf函数并不知道参数个数，它的内部有个指针，用来索检格式化字符串。对于特定类型%，就去取相应参数的值，直到索检到格式化字符串结束。所以尽管没有参数，上面的代码也会将format string后面的内存当做参数以16进制输出，这样就造成了内存泄露。
printf有一个不常见的格式化字符串%n，它的功能是将%n之前打印出来的字符个数，赋值给一个变量。这样可以通过前面的方法找到参数的地址，再通过%n修改参数的值。(读取的话通过%s即可）
防护方法：
1.不要将客户端输入的字符串作为格式化字符串。
2.对于客户端提交过来的格式化字符串进行过滤或转义（将%删除或转义）。

https://blog.csdn.net/qq_43394612/article/details/84900668

整数溢出
整数分为无符号整数以及有符号整数两种。其中有符号整数会在最高位用0表示正数，用1表示负数，无符号整数则没有这种限制，其之间操作会存在上溢和下溢。常见的整数类型有8位（单字节字符、布尔类型）、16位（短整型）、32位（长整型）等，关于整数溢出，其与其它类型的溢出一样，都是将数据放入了比它本身小的存储空间中，从而出现了溢出。
1.无符号整数的下溢和上溢，可能导致系统无法操作过大的地址空间，导致程序崩溃。
2.符号的问题有以下三点是需要注意的，其可能导致逻辑问题或程序崩溃。
（1）有符号整数之间的比较。
（2）有符号整数的运算。
（3）无符号整数和有符号整数的对比。
3.截断问题主要发生在高位数的整数（如32位）复制到低位数的整数（如16位）的时候，发生的溢出现象。
另外，整数溢出在很多时候会导致缓冲区溢出漏洞的发生，但并不是所有由整数溢出导致的缓冲区溢出都是可以被利用的，原因就在于涉及诸如4GB大小的内存空间操作时会发生错误。