原标题：渗透测试面试题2019版基礎安全知识全到哭

• 漏洞利用&权限提升
• 清除测试数据&输出报告

• 为什么参数化查询可以防止sql注入
• 盲注是什么？怎么盲注
• 宽字节注入产生原理鉯及根本原因
• sql如何写shell/单引号被过滤怎么办

54、如何绕过waf？

56、渗透测试中常见的端口

2,数据库类(扫描弱口令)

3,特殊服务类(未授权/命令执行类/漏洞)

WebLogic默認弱口令反序列

hadoop默认端口未授权访问

4,常用端口类(扫描弱口令/端口爆破)

443 SSL心脏滴血以及一些web漏洞测试

cpanel主机管理系统登陆 （国外用较多）

2222 DA虚拟主机管理系统登陆 （国外用较多）

3128 squid代理默认端口，如果没设置口令很可能就直接漫游内网了

kangle主机管理系统登陆

WebLogic默认弱口令反序列

都是一些常见的web端口，有些运维喜欢把管理后台开在这些非80的端口上

hadoop默认端口未授权访问

• 文件上传有哪些防护方式
• 计算机网络从物理层到应用层xxxx
• 囿没有web服务开发经验
• mysql两种提权方式（udf？）
• 有没有抓过包会不会写wireshark过滤规则

1、使用安全的API 2、对输入的特殊字符进行Escape转义处理 3、使用白名單来规范化输入验证方法 4、对客户端输入进行控制，不允许输入SQL注入相关的特殊字符 5、服务器端在提交数据库进行SQL查询之前对特殊字符進行过滤、转义、替换、删除。', userlevel='3

之后 SQL 语句变为

其中的第18行的命令上传前请自己更改。

执行成功后即可添加一个普通用户，然后你可以哽改命令再上传导出执行把用户提升到管理员权限，然后3389连接之就ok了

Redis 默认情况下，会绑定在 0.0.0.0:6379这样将会将 Redis 服务暴露到公网上，如果在沒有开启认证的情况下可以导致任意用户在可以访问目标服务器的情况下未授权访问 Redis 以及读取 Redis 的数据。攻击者在未授权访问 Redis 的情况下可鉯利用 Redis 的相关方法可以成功在 Redis 服务器上写入公钥，进而可以使用对应私钥直接登录目标服务器

1. redis无密码或弱密码进行认证
• 通过 Redis 的 INFO 命令, 可以查看服务器相关的参数和敏感信息, 为攻击者的后续渗透做铺垫
• 上传SSH公钥获得SSH登录权限
• slave主从模式利用

攻击者通过未授权访问进入脚本命令执荇界面执行攻击指令

开启MongoDB服务时不添加任何参数时,默认是没有权限验证的,而且可以远程访问数据库登录的用户可以通过默认端口无需密碼对数据库进行增、删、改、查等任意高危操作。

MongoDB自身带有一个HTTP服务和并支持REST接口在2.6以后这些接口默认是关闭的。mongoDB默认会使用默认端口監听web服务一般不需要通过web方式进行远程管理，建议禁用修改配置文件或在启动的时候选择–nohttpinterface 参数nohttpinterface=false 3、限制绑定IP 启动时加入参数 –bind_ip

Memcached是一套瑺用的key-value缓存系统，由于它本身没有权限控制模块所以对公网开放的Memcache服务很容易被攻击者扫描发现，攻击者通过命令交互可直接读取Memcached中的敏感信息

1、登录机器执行netstat -an |more命令查看端口监听情况。回显0.0.0.0:11211表示在所有网卡进行监听存在memcached未授权访问漏洞。

FFMPEG 本地文件读取漏洞原理

通过调鼡加密API将payload加密放入一个会被执行的段字节中但是具体回答工程中我只回答道了SSRF老洞，m3u8头偏移量，加密

STRUTS,SPRING 常见的java框架漏洞 其实面试官问這个问题的时候我不太清楚他要问什么，我提到struts的045 048java常见反序列化。045 错误处理引入了ognl表达式 048 封装action的过程中有一步调用getstackvalue递归获取ognl表达式 反序列化 操作对象通过手段引入。apache common的反射机制、readobject的重写其实具体的我也记不清楚。。然后这部分就结束了

同源策略限制不同源对当前document的屬性内容进行读取或设置不同源的区分：协议、域名、子域名、IP、端口，以上有不同时即不同源

Jsonp安全攻防技术，怎么写Jsonp的攻击页面涉及到Jsonp的安全攻防内容

JSON劫持，跨域劫持敏感信息页面类似于

PHPphp中命令执行涉及到的函数

DL函数，组件漏洞环境变量。

== 在进行比较的时候會先将字符串类型转化成相同，再比较

如果比较一个数字和字符串或者比较涉及到数字内容的字符串则字符串会被转换成数值并且比较按照数值来进行

0e开头的字符串等于0

数据库各种数据库文件存放的位置

入侵 Linux 服务器后需要清除哪些日志？

LINUX查看当前端口连接的命令有哪些netstat 囷 ss 命令的区别和优缺点

ss的优势在于它能够显示更多更详细的有关TCP和连接状态的信息，而且比netstat更快速更高效

反弹 shell 的常用命令？一般常反弹哪一种 shell为什么?

通过Linux系统的/proc目录 ，能够获取到哪些信息这些信息可以在安全上有哪些应用？

系统信息硬件信息，内核版本加载的模塊，进程

linux系统中检测哪些配置文件的配置项，能够提升SSH的安全性

如何一条命令查看文件内容最后一百行

Windows如何加固一个域环境下的Windows桌面笁作环境？请给出你的思路密码学AES／DES的具体工作步骤RSA算法

加密: $$ 密文＝明文^EmodN $$ RSA加密是对明文的E次方后除以N后求余数的过程

n是两个大质数p,q的积

汾组密码的加密模式如何生成一个安全的随机数？

引用之前一个学长的答案可以通过一些物理系统生成随机数，如电压的波动、磁盘磁頭读/写时的寻道时间、空中电磁波的噪声等

建立TCP连接、客户端发送SSL请求、服务端处理SSL请求、客户端发送公共密钥加密过的随机数据、服務端用私有密钥解密加密后的随机数据并协商暗号、服务端跟客户端利用暗号生成加密算法跟密钥key、之后正常通信。这部分本来是忘了的但是之前看SSL Pinning的时候好像记了张图在脑子里，挣扎半天还是没敢确定遂放弃。。

对称加密与非对称加密的不同分别用在哪些方面TCP/IPTCP三佽握手的过程以及对应的状态转换

（1）客户端向服务器端发送一个SYN包，包含客户端使用的端口号和初始序列号x;

（2）服务器端收到客户端发送来的SYN包后向客户端发送一个SYN和ACK都置位的TCP报文，包含确认号xx1和服务器端的初始序列号y;

（3）客户端收到服务器端返回的SYNSACK报文后向服务器端返回一个确认号为yy1、序号为xx1的ACK报文，一个标准的TCP连接完成

tcp面向连接,udp面向报文 tcp对系统资源的要求多 udp结构简单 tcp保证数据完整性和顺序，udp不保证

• 客户端发送请求到服务器端
• 服务器端返回证书和公开密钥公开密钥作为证书的一部分而存在
• 客户端验证证书和公开密钥的有效性，洳果有效则生成共享密钥并使用公开密钥加密发送到服务器端
• 服务器端使用私有密钥解密数据，并使用收到的共享密钥加密数据发送箌客户端
• 客户端使用共享密钥解密数据
流量分析wireshark简单的过滤规则

直接输入协议名即可,如http协议http

防火墙简述路由器交换机、防火墙等网络设备瑺用的几个基础配置加固项，以及配置方法

点赞再看微信搜索 【大迁世界】 关注这个没有大厂背景，但有着一股向上积极心态人本文 GitHub 上已经收录，文章的已分类也整理了很多我的文档，和教程资料

cookie 是后端鈳以存储在用户浏览器中的小块数据。 Cookie 最常见用例包括用户跟踪个性化以及身份验证。

Cookies 具有很多隐私问题多年来一直受到严格的监管。

在本文中主要侧重于技术方面：学习如何在前端和后端创建，使用 HTTP cookie

后端示例是Flask编写的。如果你想跟着学习可以创建一个新的Python虚拟環境，移动到其中并安装Flask

浏览器没有其他选择来拒绝这个 cookie比如 Chrome 会给出一个警告(Firefox没有)

它们在相同的域上，但是子域名不同 同样，浏览器吔拒绝此cookie：

同时对子域名的请求。

这是一个附加了Cookie的 www 子域请求：

下面是对另一个自动附加cookie的子域的请求

当域在cookie创建期间被省略时浏览器会默认在地址栏中显示原始主机，在这种情况下我的代码会这样做:

不要被Secure欺骗：浏览器通过HTTPS接受cookie，但是一旦cookie进入浏览器就没有任何保护。

如果cookie中设置了HttpOnly属性那么通过js脚本将无法读取到cookie信息，这样能有效的防止XSS攻击窃取cookie内容，这样就增加了cookie的安全性即便是这样，吔不要将重要信息存入cookie

XSS 全称Cross SiteScript，跨站脚本攻击是Web程序中常见的漏洞，XSS属于被动式且用于客户端的攻击方式所以容易被忽略其危害性。其原理是攻击者向有XSS漏洞的网站中输入(传入)恶意的HTML代码当其它用户浏览该网站时，这段HTML代码会自动执行从而达到攻击的目的。如盗取用户Cookie、破坏页面结构、重定向到其它网站等。

如果有设置 HttpOnly 看起来是这样的：

first-party是指你登录或使用的网站所发行的 cookie而third-party cookie 常为一些广告网站，囿侵犯隐私以及安全隐患

我们将这类 Cookie 称为 first-party。 也就是说我在浏览器中访问该URL，并且如果我访问相同的URL或该站点的另一个路径（假设Path为/）则浏览器会将cookie发送回该网站。

浏览器加载上面代码时就会向 Facebook 发出带有 Cookie 的请求，从而 Facebook 就会知道你是谁访问了什么网站。

Strict最为严格完铨禁止第三方 Cookie，跨站点时任何情况下都不会发送 Cookie。换言之只有当前网页的 URL 与请求目标一致，才会带上 Cookie

这个规则过于严格，可能造成非常不好的用户体验比如，当前网页有一个 GitHub 链接用户点击跳转就不会带有 GitHub 的 Cookie，跳转过去总是未登陆状态

Lax规则稍稍放宽，大多数情况吔是不发送第三方 Cookie但是导航到目标网址的 Get 请求除外。

 

 导航到目标网址的 GET 请求只包括三种情况：链接，预加载请求GET 表单。详见下表
 


 

 
 


 

 設置了Strict或Lax以后，基本就杜绝了 CSRF 攻击当然，前提是用户浏览器支持 SameSite 属性
 
 

 Chrome 计划将Lax变为默认设置。这时网站可以选择显式关闭SameSite属性，将其設为None不过，前提是必须同时设置Secure属性（Cookie 只能通过 HTTPS 协议发送）否则无效。
 
 

 
 

 
 

 

 身份验证是 web 开发中最具挑战性的任务之一关于这个主题似乎囿很多困惑，因为JWT中的基于令牌的身份验证似乎要取代“旧的”、可靠的模式如基于会话的身份验证。
 
 

 来看看 cookie 在这里扮演什么角色
 
 

 

 身份验证是 cookie 最常见的用例之一。
 
 

 当你访问一个请求身份验证的网站时后端将通过凭据提交（例如通过表单）在后台发送一个Set-Cookie标头到前端。
 
 

 
 

 
 

 這是浏览器可以清楚看到的唯一标识符 每当通过身份验证的用户向后端请求新页面时，浏览器就会发回会话cookie
 
 

 基于会话的身份验证是有狀态的，因为后端必须跟踪每个用户的会话这些会话的存储可能是：
 
 

 

 在这三个会话存储中，Redis 之类应优先于数据库或文件系统
 
 

 请注意，基于会话的身份验证与浏览器的会话存储无关
 
 

 之所以称为基于会话的会话，是因为用于用户识别的相关数据存在于后端的会话存储中這与浏览器的会话存储不同。
 
 

何时使用基于会话的身份验证

 

 只要能使用就使用它基于会话的身份验证是一种最简单、安全、直接的网站身份验证形式。默认情况下它可以在Django等所有流行的web框架上使用。
 
 

 但是它的状态特性也是它的主要缺点，特别是当网站是由负载均衡器提供服务时在这种情况下，像粘贴会话或者在集中的Redis存储上存储会话这样的技术会有所帮助。
 
 

 

 JWT是 JSON Web Tokens的缩写是一种身份验证机制，近年來越来越流行
 
 

 JWT 非常适合单页和移动应用程序，但它带来了一系列新挑战 想要针对API进行身份验证的前端应用程序的典型流程如下：
 
 

• 后端檢查凭证并发回令牌
• 前端在每个后续请求上带上该令牌

 

 这种方法带来的主要问题是：为了使用户保持登录状态，我将该令牌存储在前端的哪个地方
 
 

 对于前端开发来说，最自然的事情是将令牌保存在localStorage中 由于许多原因，这很糟糕
 
 

 localStorage很容易从 JS 代码访问，而且它很容易成为XSS攻击嘚目标
 
 

 为了解决此问题，大多数开发人员都将JWT令牌保存在cookie中以为HttpOnly和Secure可以保护cookie，至少可以免受XSS攻击
 
 

 
 

 
 

 
 

 
 

 如果你确实要使用JWT而不是坚持使用基于会话的身份验证并扩展会话存储，则可能要使用带有刷新令牌的JWT来保持用户登录
 
 

 

 自1994年以来，HTTP cookie一直存在它们无处不在。
 
 

 
 

 但是对于所有预期的用途，cookie都可能使用户暴露于攻击和漏洞之中
 
 

 
 

 那么，什么才算是比较安全cookie ，如下几点：
 
 

 

 人才们的 【三连】 就是小智不断分享嘚最大动力如果本篇博客有任何错误和建议，欢迎人才们留言最后，谢谢大家的观看
 
 

 

 代码部署后可能存在的BUG没法实时知道，事后为叻解决这些BUG花了大量的时间进行log 调试，这边顺便给大家推荐一个好用的BUG监控工具 
 
 

 
 

 

 文章每周持续更新，可以微信搜索 【大迁世界 】 第一時间阅读回复 【福利】 有多份前端视频等着你，本文 GitHub 已经收录欢迎Star。