Posts

课件下载1 课件下载2

课件下载

课件下载

SQL注入之文件读写 文件读写注入的原理 就是利用文件的读写权限进行注入，它可以写入一句话木马，也可以读取系统文件的敏感信息。 文件读写注入的条件 高版本的MYSQL添加了一个新的特性secure_file_priv，该选项限制了mysql导出文件的权限 secure_file_priv选项 linux cat etc/conf win www/mysql / my.ini show global variables like ‘%secure%’ 查看mysql全局变量的配置 1、读写文件需要 secure_file_priv权限 secure_file_priv= 代表对文件读写没有限制 secure_file_priv=NULL 代表不能进行文件读写 secure_file_priv=d:/phpstudy/mysql/data 代表只能对该路径下文件进行读写 2、知道网站绝对路径 Windows常见： Linux常见： 路径获取常见方式： 报错显示，遗留文件，漏洞报错，平台配置文件等 读取文件 使用函数：load_file() 后面的路径可以是单引号，0x，char转换的字符。 注意：路径中斜杠是/不是\。 一般可以与union中做为一个字段使用，查看config.php(即mysql的密码)，apache配置… 写入文件 使用函数：Into Outfile（能写入多行，按格式输出）和 into Dumpfile（只能写入一行且没有输出格式） outfile 后面不能接0x开头或者char转换以后的路径，只能是单引号路径 SQL注入之基础防御 魔术引号 魔术引号（Magic Quote）是一个自动将进入 PHP 脚本的数据进行转义的过程。 最好在编码时不要转义而在运行时根据需要而转义。 魔术引号： 在php.ini文件内找到 magic_quotes_gpc = On 开启 将其改为 magic_quotes_gpc = Off 关闭 内置函数 做数据类型的过滤 is_int()等 addslashes() mysql_real_escape_string() mysql_escape_string() 自定义关键字 str_replace() ...

2022年12月29日晚，我在这台服务器上安装了docker，之后再面板首页更新面板 2022年12月30日中午，当我想整理服务器文件时，发现宝塔面板已经没法登上去。我照常打开了Xshell，以为是宝塔输入界面的安全地址因为自动更换了，所以输入bt 14想看看更新的安全通道地址是什么 嗯…好像一切都挺正常的，地址也没错，但还是登不上去，是什么原因呢？不管了，先重启一波面板，嗯…还是不行？那就重启服务器试试 重启完后按理说应该已经没问题才对，可还是不行。这时候当我再次查看bt 14，好家伙，给我变成这样了 而且当我登入小屋网站后，发现原本正常的小屋竟然也变成了这样 当我正为此傻眼的时候，我还不知道，整整两天的服务器维修之旅才就此展开… 首先我执行了bt 16，抱着试一试面板自动修复的心态，等来了一串完全看不懂的报错信息— 这是啥？没见过，百度看看有没有解决方案 遗憾的是，经过大半天的搜索，这一次百度并不能帮我找到答案 不过根据报错信息和经验来看，我还是能隐隐约约知道问题所在大概就是以下几点造成的： 服务器python版本不兼容 pip未知文件冲突 随后我便立马向群里发出求救 尽管如同家人般的群友提供了一些帮助后，还是没能找到答案 随即我又找到了宝塔的官方客服，可是客服也没能给我答案，让我去论坛上发帖求助 不过之后群友发来的一个博客让我知道了问题根源所在 requests库的Failed to establish a new connection 一模一样的报错！这下可算知道报错原因，但这个原因很明显就是因为宝塔本身产品设计缺陷引起的，而我也并没有找到报错文件相关的官方技术文档，所以从根源上解决问题这条路已经可以宣告失败了 无奈之下，只好想其他方法。首要任务是保住小屋的数据。根据小屋的页面来看，nginx服务器是正常的，可是为什么没法正常显示我部署的文档内容呢？直觉告诉我应该是因为当时这个nginx是我在宝塔上下载的，所以和宝塔文件多少应该有点牵连。其中很重要的一点就是，我没有在nginx.conf里找到server函数。这也就更加证实了这个猜想，这个函数应该是被放在宝塔产品本身的某个已经损坏的文件里。 由于当时我也没有在宝塔上创建FTP用户，所以使用FTP备份文件也不可能了。 时间来到第二天中午，当我再次打开Xshell，发现连bt命令都已经执行不了，而很多linux命令也都无法执行。 最后只能求助淘宝，请宝塔运维工程师帮忙修复。可是问了许多家店也都表示“修不了”然后拒绝了我的请求。 直到后来找到一家店，店家同意帮我备份数据，可是要想修复损坏的系统文件和宝塔是做不了。 好在店家想到了用Navicat帮我先备份出数据库，再用XS导出文件。前后花了一个下午才跟支离破碎的服务器建立链接保住资源。 （店铺名也给大家，帮他家做个广告嘿嘿） 而根据店家介绍，用debian做服务器系统的已经很少，更多是用Ubuntu和Centos 于是那晚修完服务器的我愤怒地在空间里发了一条说说 总结一下，希望给自己和大家一个教训，一定要定期备份自己的服务器数据，否则很有可能出现像我这种情况后服务器内容备份不出来最后造成的惨案。