51、img标签除了onerror属性外，还有其他获取管理员路径的办法吗？
src指定一个远程的脚本文件，获取referer
52、img标签除了onerror属性外，并且src属性的后缀名，必须以.jpg结尾，怎么获取管理员路径。
1）远程服务器修改apache配置文件，配置.jpg文件以php方式来解析 AddType application/x-httpd-php .jpg 会以php方式来解析
53、为什么aspx木马权限比asp大？
aspx使用的是.net技术。IIS 中默认不支持，ASP只是脚本语言而已。入侵的时候asp的木马一般是guest权限…APSX的木马一般是users权限。
54、如何绕过waf？
大小写转换法 干扰字符 /!/ 编码 base64 unicode hex url ascll 复参数
55、如何向服务器写入webshell？
各种上传漏洞mysql具有写入权限,用sql语句写入shellhttp put方法
56、渗透测试中常见的端口
a、web类(web漏洞/敏感目录) 第三方通用组件漏洞struts thinkphp jboss ganglia zabbix
80 web 80-89 web 8000-9090 web
b、数据库类(扫描弱口令)
1433 MSSQL 1521 Oracle 3306 MySQL 5432 PostgreSQL
c、特殊服务类(未授权/命令执行类/漏洞)
443 SSL心脏滴血 873 Rsync未授权 5984 CouchDB http://xxx:5984/_utils/ 6379 redis未授权 7001,7002 WebLogic默认弱口令，反序列 9200,9300 elasticsearch 参考WooYun: 多玩某服务器ElasticSearch命令执行漏洞 11211 memcache未授权访问 27017,27018 Mongodb未授权访问 50000 SAP命令执行 50070,50030 hadoop默认端口未授权访问
d、常用端口类(扫描弱口令/端口爆破)
21 ftp 22 SSH 23 Telnet 2601,2604 zebra路由，默认密码zebra3389 远程桌面
ALL、端口合计详情
21 ftp 22 SSH 23 Telnet 80 web 80-89 web 161 SNMP 389 LDAP 443 SSL心脏滴血以及一些web漏洞测试 445 SMB 512,513,514 Rexec 873 Rsync未授权 1025,111 NFS 1433 MSSQL 1521 Oracle:(iSqlPlus Port:5560,7778) 2082/2083 cpanel主机管理系统登陆 （国外用较多）2222 DA虚拟主机管理系统登陆 （国外用较多） 2601,2604 zebra路由，默认密码zebra3128 squid代理默认端口，如果没设置口令很可能就直接漫游内网了 3306 MySQL 3312/3311 kangle主机管理系统登陆 3389 远程桌面 4440 rundeck 参考WooYun: 借用新浪某服务成功漫游新浪内网 5432 PostgreSQL 5900 vnc 5984 CouchDB http://xxx:5984/_utils/ 6082 varnish 参考WooYun: Varnish HTTP accelerator CLI 未授权访问易导致网站被直接篡改或者作为代理进入内网 6379 redis未授权 7001,7002 WebLogic默认弱口令，反序列 7778 Kloxo主机控制面板登录 8000-9090 都是一些常见的web端口，有些运维喜欢把管理后台开在这些非80的端口上 8080 tomcat/WDCP主机管理系统，默认弱口令 8080,8089,9090 JBOSS 8083 Vestacp主机管理系统 （国外用较多） 8649 ganglia 8888 amh/LuManager 主机管理系统默认端口 9200,9300 elasticsearch 参考WooYun: 多玩某服务器ElasticSearch命令执行漏洞 10000 Virtualmin/Webmin 服务器虚拟主机管理系统 11211 memcache未授权访问 27017,27018 Mongodb未授权访问 28017 mongodb统计页面 50000 SAP命令执行 50070,50030 hadoop默认端口未授权访问
三、深信服一面
- 了解哪些漏洞
- 文件上传有哪些防护方式
- 用什么扫描端口，目录
- 如何判断注入
- 注入有防护怎么办
- 有没有写过tamper
- 3306 1443 8080是什么端口
- 计算机网络从物理层到应用层xxxx
- 有没有web服务开发经验
- 如何向服务器写入webshell
- 有没有用过xss平台
- 网站渗透的流程
- mysql两种提权方式（udf，？）
- 常见加密方式xxx
- ddos如何防护
- 有没有抓过包，会不会写wireshark过滤规则
- 清理日志要清理哪些
四、SQL注入防护
1、使用安全的API
2、对输入的特殊字符进行Escape转义处理
3、使用白名单来规范化输入验证方法
4、对客户端输入进行控制，不允许输入SQL注入相关的特殊字符
5、服务器端在提交数据库进行SQL查询之前，对特殊字符进行过滤、转义、替换、删除。
6、规范编码,字符集
五、为什么参数化查询可以防止SQL注入
原理:
使用参数化查询数据库服务器不会把参数的内容当作sql指令的一部分来执行，是在数据库完成sql指令的编译后才套用参数运行
简单的说: 参数化能防注入的原因在于,语句是语句，参数是参数，参数的值并不是语句的一部分，数据库只按语句的语义跑
六、SQL头注入点
UAREFERERCOOKIEIP
七、盲注是什么？怎么盲注？
盲注是在SQL注入攻击过程中，服务器关闭了错误回显，我们单纯通过服务器返回内容的变化来判断是否存在SQL注入和利用的方式。盲注的手段有两种，一个是通过页面的返回内容是否正确(boolean-based)，来验证是否存在注入。一个是通过sql语句处理时间的不同来判断是否存在注入(time-based)，在这里，可以用benchmark，sleep等造成延时效果的函数，也可以通过构造大笛卡儿积的联合查询表来达到延时的目的。
八、宽字节注入产生原理以及根本原因
1、产生原理
在数据库使用了宽字符集而WEB中没考虑这个问题的情况下，在WEB层，由于0XBF27是两个字符，在PHP中比如addslash和magic_quotes_gpc开启时，由于会对0x27单引号进行转义，因此0xbf27会变成0xbf5c27,而数据进入数据库中时，由于0XBF5C是一个另外的字符，因此\转义符号会被前面的bf带着"吃掉"，单引号由此逃逸出来可以用来闭合语句。
2、在哪里编码
3、根本原因
character_set_client(客户端的字符集)和character_set_connection(连接层的字符集)不同,或转换函数如，iconv、mb_convert_encoding使用不当。
4、解决办法
统一数据库、Web应用、操作系统所使用的字符集，避免解析产生差异，最好都设置为UTF-8。或对数据进行正确的转义，如mysql_real_escape_string+mysql_set_charset的使用。
5、SQL里面只有update怎么利用
先理解这句 SQL
UPDATE user SET password='MD5($password)', homepage='$homepage' WHERE id='$id'
如果此 SQL 被修改成以下形式，就实现了注入
a、修改 homepage 值为http://xxx.net', userlevel='3
之后 SQL 语句变为
UPDATE user SET password='mypass', homepage='http://xxx.net', userlevel='3' WHERE id='$id'
userlevel 为用户级别
b、修改 password 值为mypass)' WHERE username='admin'#
之后 SQL 语句变为
UPDATE user SET password='MD5(mypass)' WHERE username='admin'#)', homepage='$homepage' WHERE id='$id'
c、修改 id 值为' OR username='admin'之后 SQL 语句变为
UPDATE user SET password='MD5($password)', homepage='$homepage' WHERE id='' OR username='admin'
九、SQL如何写shell/单引被过滤怎么办
写shell: root权限，GPC关闭，知道文件路径 outfile函数
http://127.0.0.1:81/sqli.php?id=1 into outfile 'C:\\wamp64\\www\\phpinfo.php' FIELDS TERMINATED BY '<?php phpinfo(); ?>'
http://127.0.0.1:81/sqli.php?id=-1 union select 1,0x3c3f70687020706870696e666f28293b203f3e,3,4 into outfile 'C:\\wamp64\\www\\phpinfo.php'宽字节注入
1、代替空格的方法
%0a、%0b、%a0 等/**/ 等注释符<>
2、mysql的网站注入，5.0以上和5.0以下有什么区别
5.0以下没有information_schema这个系统表，无法列表名等，只能暴力跑表名。
5.0以下是多用户单操作，5.0以上是多用户多操做。
十、XSS
1、XSS原理
反射型
用户提交的数据中可以构造代码来执行，从而实现窃取用户信息等攻击。需要诱使用户“点击”一个恶意链接，才能攻击成功
存储型
存储型XSS会把用户输入的数据“存储”在服务器端。这种XSS具有很强的稳定性。
DOM型
通过修改页面的DOM节点形成的XSS，称之为DOM Based XSS。
2、DOM型和反射型的区别
反射型XSS：通过诱导用户点击，我们构造好的恶意payload才会触发的XSS。反射型XSS的检测我们在每次请求带payload的链接时页面应该是会带有特定的畸形数据的。DOM型：通过修改页面的DOM节点形成的XSS。DOM-based XSS由于是通过js代码进行dom操作产生的XSS，所以在请求的响应中我们甚至不一定会得到相应的畸形数据。根本区别在我看来是输出点的不同。
3、DOM型和XSS自动化测试或人工测试
人工测试思路：找到类似document.write、innerHTML赋值、outterHTML赋值、window.location操作、写javascript:后内容、eval、setTimeout 、setInterval 等直接执行之类的函数点。找到其变量，回溯变量来源观察是否可控，是否经过安全函数。自动化测试参看道哥的博客，思路是从输入入手，观察变量传递的过程，最终检查是否有在危险函数输出，中途是否有经过安全函数。但是这样就需要有一个javascript解析器，否则会漏掉一些通过js执行带入的部分内容。
在回答这段问题的时候，由于平时对客户的检测中，基本是凭借不同功能点的功能加上经验和直觉来进行检测，对不同类型的XSS检测方式实际上并没有太过细分的标准化检测方式，所以回答的很烂。。。
4、如何快速发现XSS位置
5、对于XSS怎么修补建议
输入点检查：对用户输入的数据进行合法性检查，使用filter过滤敏感字符或对进行编码转义，针对特定类型数据进行格式检查。针对输入点的检查最好放在服务器端实现。
输出点检查：对变量输出到HTML页面中时，对输出内容进行编码转义，输出在HTML中时，对其进行HTMLEncode，如果输出在Javascript脚本中时，对其进行JavascriptEncode。对使用JavascriptEncode的变量都放在引号中并转义危险字符，data部分就无法逃逸出引号外成为code的一部分。还可以使用更加严格的方法，对所有数字字母之外的字符都使用十六进制编码。此外，要注意在浏览器中，HTML的解析会优先于Javascript的解析，编码的方式也需要考虑清楚，针对不同的输出点，我们防御XSS的方法可能会不同，这点可能在之后的文章会做下总结。
除此之外，还有做HTTPOnly对Cookie劫持做限制。
6、XSS蠕虫的生产条件
正常情况下，一个是产生XSS点的页面不属于self页面，用户之间产生交互行为的页面，都可能造成XSS Worm的产生。
不一定需要存储型XSS
十一、CSRF
1、CSRF原理
CSRF是跨站请求伪造攻击，由客户端发起,是由于没有在关键操作执行时进行是否由用户自愿发起的确认
2、防御
验证Referer
添加token
3、token和referer做横向对比，谁安全等级高？
token安全等级更高，因为并不是任何服务器都可以取得referer，如果从HTTPS跳到HTTP，也不会发送referer。并且FLASH一些版本中可以自定义referer。但是token的话，要保证其足够随机且不可泄露。(不可预测性原则)
4、对referer的验证，从什么角度去做？如果做，怎么杜绝问题
对header中的referer的验证，一个是空referer，一个是referer过滤或者检测不完善。为了杜绝这种问题，在验证的白名单中，正则规则应当写完善。
5、针对token,对token测试会注意哪方面被人，会对token的哪方面进行测试？
引用一段请教前辈的回答：
针对token的攻击，一是对它本身的攻击，重放测试一次性、分析加密规则、校验方式是否正确等，二是结合信息泄露漏洞对它的获取，结合着发起组合攻击信息泄露有可能是缓存、日志、get，也有可能是利用跨站很多跳转登录的都依赖token，有一个跳转漏洞加反射型跨站就可以组合成登录劫持了另外也可以结合着其它业务来描述token的安全性及设计不好怎么被绕过比如抢红包业务之类的
十一、SSRF
SSRF(Server-Side Request Forgery:服务器端请求伪造) 是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。一般情况下，SSRF攻击的目标是从外网无法访问的内部系统。（正是因为它是由服务端发起的，所以它能够请求到与它相连而与外网隔离的内部系统）
SSRF 形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制。比如从指定URL地址获取网页文本内容，加载指定地址的图片，下载等等。
1、监测
SSRF漏洞的验证方法：
1）因为SSRF漏洞是让服务器发送请求的安全漏洞，所以我们就可以通过抓包分析发送的请求是否是由服务器的发送的，从而来判断是否存在SSRF漏洞
2）在页面源码中查找访问的资源地址 ，如果该资源地址类型为 www.baidu.com/xxx.php?image=（地址）的就可能存在SSRF漏洞 4[1]
2、SSRF漏洞的成因 防御 绕过
成因：模拟服务器对其他服务器资源进行请求，没有做合法性验证。利用：构造恶意内网IP做探测，或者使用其余所支持的协议对其余服务进行攻击。防御：禁止跳转，限制协议，内外网限制，URL限制。绕过：使用不同协议，针对IP，IP格式的绕过，针对URL，恶意URL增添其他字符，@之类的。301跳转+dns rebindding。
十二、上传
1、文件上传漏洞原理
由于程序员在对用户文件上传部分的控制不足或者处理缺陷，而导致用户可以越过其本身权限向服务器上传可执行的动态脚本文件
2、常见的上传绕过方式
前端js验证：禁用js/burp改包
大小写
双重后缀名
过滤绕过 pphphp->php
3、防护
文件上传目录设置为不可执行
使用白名单判断文件上传类型
用随机数改写文件名和路径
4、审查上传点的元素有什么意义？
有些站点的上传文件类型的限制是在前端实现的，这时只要增加上传类型就能突破限制了。
十三、文件包含
1、原理
引入一段用户能控制的脚本或代码，并让服务器端执行 include()等函数通过动态变量的方式引入需要包含的文件；
用户能够控制该动态变量。
2、导致文件包含的函数
PHP：include(), include_once(), require(), re-quire_once(), fopen(), readfile(), … JSP/Servlet：ava.io.File(), java.io.Fil-eReader(), … ASP：include file, include virtual,
3、本地文件包含
能够打开并包含本地文件的漏洞，被称为本地文件包含漏洞
十四、逻辑漏扫
1、金融行业常见逻辑漏洞
单针对金融业务的 主要是数据的篡改(涉及金融数据，或部分业务的判断数据)，由竞争条件或者设计不当引起的薅羊毛，交易/订单信息泄露，水平越权对别人的账户查看或恶意操作，交易或业务步骤绕过。
十五、中间人攻击
中间人攻击是一个（缺乏）相互认证的攻击；由于客户端与服务器之间在SSL握手的过程中缺乏相互认证而造成的漏洞
防御中间人攻击的方案通常基于一下几种技术
1.公钥基础建设PKI 使用PKI相互认证机制，客户端验证服务器，服务器验证客户端；上述两个例子中都是只验证服务器，这样就造成了SSL握手环节的漏洞，而如果使用相互认证的的话，基本可以更强力的相互认证
2.延迟测试
使用复杂加密哈希函数进行计算以造成数十秒的延迟；如果双方通常情况下都要花费20秒来计算，并且整个通讯花费了60秒计算才到达对方，这就能表明存在第三方中间人。
3.使用其他形式的密钥交换形式
ARP欺骗
原理
每台主机都有一个ARP缓存表，缓存表中记录了IP地址与MAC地址的对应关系，而局域网数据传输依靠的是MAC地址。在ARP缓存表机制存在一个缺陷，就是当请求主机收到ARP应答包后，不会去验证自己是否向对方主机发送过ARP请求包，就直接把这个返回包中的IP地址与MAC地址的对应关系保存进ARP缓存表中，如果原有相同IP对应关系，原有的则会被替换。这样攻击者就有了偷听主机传输的数据的可能
防护
1.在主机绑定网关MAC与IP地址为静态（默认为动态），命令：arp -s 网关IP 网关MAC
2.在网关绑定主机MAC与IP地址
3.使用ARP防火墙