介绍移动安全框架(MobSF)是一个自动化、一体化的移动应用程序(Android/iOS/Windows)渗透测试、恶意软件分析和安全评估框架,能够执行静态和动态分析。MobSF 支持移动应用程序二进制文件(APK、XAPK、IPA 和 APPX)以及压缩的源代码,并提供 REST API,以便与 CI/CD 或 DevSecOps 管道无缝集成。动态分析器帮助您执行运行时安全性评估和交互式检测测试。
如果使用 Docker 部署的话,Docker 不支持动态分析。
GitHub地址:
https://github.com/MobSF/Mobile-Security-Framework-MobSF
安装前准备1.安装 Git2.安装 Python >10 (需要配置环境变量)3.安装 JDK 8+ (需要配置环境变量)4.安装 Microsoft Visual C++ Build Tools5.安装 OpenSSL (non-light) (建议直接安装在默认地址)6.下载和安装 wkhtmltopdf (添加到环境变量PATH)
Git、Pyth ...
一共要下载两个东西,一个是setup.exe,一个是音源(可以配置多个音源)
下载下载setup.exe安装软件
换源
解压源.zip(音源的js文件在里面)
下载完需要配置音乐源才能使用
点击自定义源管理->本地导入
选中js文件,打开即可
点击初始化即可
导入歌单浏览器打开网易云音乐
https://music.163.com/
登录,登录之后点击头像
点击想要保存的歌单
进来之后复制一下这个
比如说我这里是
https://music.163.com/#/playlist?id=890985862
回到lx
打开之后就能看到歌单了
收藏之后在这里就能看到
不过这个收藏的歌单不会随着你网易云歌单的更新而更新
EternalBlue(在微软的MS17-010中被修复)是在Windows的SMB服务处理SMB v1请求时发生的漏洞,这个漏洞导致攻击者在目标系统上可以执行任意代码。
准备工作攻击机(kali)ip:192.168.174.130
靶机(windows server 2008 R2)ip:192.168.174.138
工具:kali自带的metasploit(msf)、nmap
利用ms17-010漏洞,靶机必须同时开启139和445端口
漏洞复现获取ip地址获取靶机ip地址
ipconfig
靶机ip地址为:192.168.174.138
获取攻击机ip地址
ifconfig
攻击机ip地址为:192.168.174.130
这里windows7虚拟机和kali都为net模式,在同一C段
测试连接看能否ping通
ping 靶机ip
ping不同的情况大概率为Windows防火墙问题,要关闭Windows防火墙(不关闭防火墙nmap扫描不到其端口,MSF利用不了永恒之蓝漏洞)
端口扫描Windows查看是否开启139和445端口
netstat -ano ...
环境漏洞服务:VSFTPD 2.3.4,俗称笑脸漏洞。存在于这个2.3.4版本,属于开发者设计上的失误。在检测到用户名带有特殊字符:)时,会自动打开6200端口。
靶机(Metasploitable2)ip:192.168.174.137
攻击机(kali)ip:192.168.174.130
漏洞复现nmap扫描靶机端口状态
开启了21号端口
继续扫描ftp服务版本号
版本号为vsftpd2.3.4,符合漏洞条件
复现方式一:nc监听利用瑞士小军刀(netcat),连接靶机的21端口,输入user带有:),pass随便输入。例如:user a:) pass 123456
此窗口不关闭,新开命令窗口测试6200端口是否开放
发现6200端口开放
nc连接6200端口,成功获得root权限
复现方式二:msf复现kali运行msfconsole进入msf
输入search vsftpd
输入use 1使用该模块
输入info查看配置信息,需要配置主机ip
配置靶机ip
输入run开始攻击,成功getshell
微信对透明背景的支持有限在我搭建个人博客时,有一个图片需要手动ps改一下,原图如下,要把左下角的2020 p成 2022
不会ps啊,找万能朋友圈吧
我用微信把图片发过去之后,朋友帮我p好了,再发给我,我发现了端倪
这怎么发过去的时候是透明的,回来的时候给我搞了个白色背景
起初我还以为是朋友的问题,又找了另一个朋友,发现也存在这个问题,于是我检查了一下我发送给我朋友的原图,用手机看了一下试试,发现原来是我的问题…(发送过去就是有白色背景的)
为什么在我电脑中这个源文件是透明背景,但是发送之后会自动被添加一个白色背景?
原来是微信的问题…(但是这里第一条可能有些问题,因为我发送的是png,对方接收到的也是png,不可能微信给我自动从png转到jpg再转到png吧)
也就是说,虽然发送之前是png,对方收到的也是png,但是微信会把包含透明背景的图片全部填充为白色
微信对透明背景的支持有限
去搜了一下解决办法
模棱两可,我选择用QQ(经过尝试QQ可以正常发送和接收透明背景的png图片)
toke的意思是“令牌”,是服务端生成的一串字符串,作为客户端进行请求的一个标识。
当用户第一次登录后,服务器生成一个token,并将此token返回给客户端,
以后客户端只需带上这个tokn前来请求数据即可,无需再次带上用户名和密码。
简单token的组成:
uid(用户唯一的身份标识)、
time(当前时间的时间戳)、
sign(签名:将请求URL、时间戳、uid进行一定的算法加密)
token是可校验的
去其他地方时,其他地方给的会员卡,会员卡就相当于token
优点:
1、与session对比,可以跨服务器
2、避免cookie存储遭受CSRF(跨站请求伪造的攻击)
以及cookie跨域限制问题(同源策略)
JWT区别:(现在常用的时JWT,之前常用的是token)
JWT:Json Web Token
有自己的一套规则
是无状态的,不用将token存储在内存或者db中
也不用自己另外去储存过期时间
token在校验用户名密码时,会存储在数据库中,并设置存储时间,校验时会比较存储时间
Tips
未读什么是Referer?Referer是HTTP请求header的一部分,当浏览器(或者模拟浏览器行为)向web服务器发送请求的时候,头信息里有包含Referer。比如我在www.sojson.com里有一个www.baidu.com链接,那么点击这个www.baidu.com,它的header信息里就有:
Referer=https://www.sojson.com
由此可以看出来吧。它就是表示一个来源。看下图的一个请求的Referer信息。
这里有一个小问题要说明下。Referer的正确英语拼法是referrer。由于早期HTTP规范的拼写错误,为了保持向后兼容就将错就错了。其它网络技术的规范企图修正此问题,使用正确拼法,所以目前拼法不统一。还有它第一个字母是大写。
Referer的作用?1.防盗链。
刚刚前面有提到一个小Demo。
我在www.sojson.com里有一个www.baidu.com链接,那么点击这个www.baidu.com,它的header信息里就有:
Referer=https://www.sojson.com
那么可以利用这个来防止盗 ...
我在看小迪的课时,看到模拟器安装xp,我在跟着操作时遇到了问题
在执行sh script.sh时产生了报错
似乎是模拟器安卓版本不同,SDK版本不同造成的问题
这个工具是使用的SDK版本更低
使用多开器新建一个7.1的安装
按照正常安装步骤
需要重启
通过xp来解除SSL证书单向检验
需要重启
成功安装证明
靶场反证书校验绕过
由于使用了xp并且使用了解除SSL证书单向检验的插件,成功抓到数据包
漏洞介绍CRLF是CR和LF两个字符的拼接,它们分别代表”回车+换行”(\r\n)“,全称为Carriage Return/Line Feed”,十六进制编码分别为0x0d和0x0a,URL编码为%0D和%0A。CR和LF组合在一起即CRLF命令,它表示键盘上的”Enter”键,许多应用程序和网络协议使用这些命令作为分隔符。
而在HTTP协议中,HTTP header之间是由一个CRLF字符序列分隔开的,HTTP Header与Body是用两个CRLF分隔的,浏览器根据这两个CRLF来取出HTTP内容并显示出来。
所以如果用户的输入在HTTP返回包的Header处回显,便可以通过CRLF来提前结束响应头,在响应内容处注入攻击脚本。因此CRLF Injection又叫HTTP响应拆分/截断(HTTP Response Splitting)简称HRS。
CRLF注入漏洞的本质和XSS有点相似,攻击者将恶意数据发送给易受攻击的Web应用程序,Web应用程序将恶意数据输出在HTTP响应头中。(XSS一般输出在主体中)
测试思路
找到输入点,构造恶意的CRLF字符
正常请求 ...
同源策略在web浏览器中,允许某个网页脚本访问另一个网页的数据,但前提是这两个网页必须同源。不同源的客户端脚本在没有明确授权的情况下,不能读写对方的资源,比如Cookie等。同源策略是一种安全思想,但并不是统一的规范体系
前端人员都懂的浏览器的同源策略,以及如何进行不同源间的相互访问_浏览器同源策略可怎么深问-CSDN博客
同源:协议、域名、端口 都相同
CSRF介绍跨站请求伪造,是一种通过挟持当前用户已登录的web应用程序从而实现非用户本意的操作的攻击方法。
攻击者通过一些技术手段,挟持用户去访问用户曾经认证过的网站并进行一些操作(例如发邮件、发信息、转账等)。由于浏览器曾经认证过,所以被访问的网站会认为是真正用户所进行的操作而去执行
与XSS相比来说,XSS可以获取用户凭证(Cookie),而CSRF只是利用用户凭证在用户不知情的情况下执行某些操作,通俗的说XSS可以执行任意JS,而CSRF只是请求伪造而已
成因没有检查Referer请求头
没有在头部设置token
危害盗取账号,以用户名义发邮件、发消息、购买商品、转账
(CSRF能做什么,取决于网站能够做什么)
攻击流程
1. ...