fiddler抓包对分析问题和排查故障来说真的很有用

问题

紧急问题,部署在IIS上的网站出现故障,用户输入用户名密码点击登陆无反应(所有用户均无法正常使用)

思路

之前听说总有人去机房偷偷看服务器,第一反应就是web.config可能出现问题(有可能被人改了),查完发现配置无误,而且udl测试数据库连接也正常。奇怪,莫非被人动了手脚?

既然config配置没有问题,那就从登录页面着手找,下面是登录按钮onclick事件一部分:

//获取传递前台的参数,UName,Pwd,Code
                var postData;
                if ($("#txtPassword").val().length == 32) {
                    postData = {
                        UName: $("#txtUserName").val(),
                        Pwd: $("#txtPassword").val(),
                        Vdate: $("#ValidateName").val(),
                        Pdcs: pdid,
                        Ypxl: ss
                    };
                }
                else {
                    postData = {
                        UName: $("#txtUserName").val(),
                        Pwd: hex_md5($("#txtPassword").val()).toUpperCase(),
                        Vdate: $("#ValidateName").val(),
                        Pdcs: pdid,
                        Ypxl: ss
                    };
                }

                //异步实现登录功能
                $.post("Login.ashx", postData, function (data) {
                    if (data == "OK") {
                        SetPwdAndChk();
						
                        window.location.href = "Index.aspx";
                    } else if (data == "Update") {
                        window.location.href = "LoginUpdate.aspx";
						
                    }
                    else if (data == "") {
                        window.location.href = "Login.aspx";
                    }
                    else {
                        pdid = parseInt(pdid) + 1;
                        setcookievalue("cs", pdid);
                        alert(data);
                        window.location.href = "Login.aspx";
                    }
                });

看上去没有任何问题,在post提交回调事件加入alert("1")调试一下,发现使用正确的用户名密码登录没有弹窗,关于登录的js脚本我确认过了没有问题,难道问题出在一般处理程序上?

打开Login.ashx发现CodeBehind、Class也正常,没有被更改,那会是哪里的问题?既然正确的用户名密码alert不执行,那么使用错误的用户名密码登录会怎么样呢?果然,错误的用户名密码走了回调函数。看到这里你有没有感觉很奇怪?

现在我们将情报整理一下

  • 数据库服务及测试连接正常、
  • web.config配置文件配置没有问题、
  • 关于登录的js脚本没有问题、
  • Login.ashx登录一般处理程序没有问题、
  • 正确的用户名密码登录不执行post回调、
  • 错误的用户名密码登录执行post回调、

这种情况如果是你你会有什么思路去排查?(前提是,你只能远程这台服务器,且服务器没有IDE环境,你又不能打开程序进行代码调试)

那么既然不能调试,看代码又看不出什么端倪来,来试试平常“干坏事儿”用的抓包吧!

关于Fiddler抓localhost,目前知道的有以下几种方法:

  • 使用http://localhost.fiddler 代替 http://localhost
  • 使用http://localhost. 代替 http://localhost
  • 使用http://127.0.0.1. 代替 http://127.0.0.1
  • ....

下面是抓取登录按钮事件的数据包:

fiddler抓包对分析问题和排查故障来说真的很有用_第1张图片

上图中的返回信息有段文字很醒目,“无法为数据库'HBNetMonitorDB'中的对象'abo.LogRecord'.'PK_LogRecord'分配空间,因为'PRIMARY'文件组已满。请删除不需要的文件、删除文件组中的对象...”

从提示信息中可以看出,原来是表空间满了,so,truncate table tablename,再次登陆,问题解决。

后续

第二天再次出现用户无法登录,检测数据上传失败的情况。。抓包后发现还是提示“无法为数据库'HBNetMonitorDB'中的对象'abo.LogRecord'.'PK_LogRecord'分配空间,因为'PRIMARY'文件组已满。请删除不需要的文件、删除文件组中的对象...”。

解决办法


    USE[master]

    GO

    ALTER DATABASE 要清理的数据库名称 SET RECOVERY SIMPLE WITH NO_WAIT

    GO

    ALTER DATABASE 要清理的数据库名称 SET RECOVERY SIMPLE   --简单模式

    GO

    USE 要清理的数据库名称

    GO

    DBCC SHRINKFILE (N'要清理的数据库名称_log' , 2, TRUNCATEONLY)  --设置压缩后的日志大小为2M,可以自行指定

    GO

    USE[master]

    GO

    ALTER DATABASE 要清理的数据库名称 SET RECOVERY FULL WITH NO_WAIT

    GO

    ALTER DATABASE 要清理的数据库名称 SET RECOVERY FULL  --还原为完全模式

    GO

上述命令做的工作是

  • 将数据库属性恢复模式设置为简单模式
  • 收缩数据库
  • 收缩完毕后还原为完整模式

你可能感兴趣的:(日常问题,渗透测试)