最近在修復系統漏洞時，使用新版AppScan掃描IIS站點（WebForm）出現一個嚴重漏洞“已解密的登陸請求”。
掃描工具修復的建議為在登陸界面不使用含“password”類型的控件或加密錄入參數。 按其所給的建議，我做了如下修改：將password控件修改為textbox控件。使用js替換輸入的內容。並將錄入的結果錄入到隱藏控件中提交時去隱藏控件的值。
修改后部署更新站點重新掃描並不能解決問題。
通過百度、bing等搜索工具找了一下兩個解決方案：
1.站點登陸采用ssl方式
2.對登陸請求的數據進行加密
因站點要求，並不能使用ssl方式，所以只能采用加密的方式來解決問題。
我使用了可逆加密方式des加密。在前端加密后再提交數據至服務端進行解密。按此種方式修改后，更新站點再進行掃描得到的結果是依然不能解決這個漏洞的問題。於是我認真查看了AppScan提交數據請求的記錄。發現我提交請求的數據，並沒有按我要求進行加密。而是在配置AppScan登陸的數據。這說明AppScan請求登陸只會根據你的配置信息來進行登陸，並不去管你的登陸是否做了其它處理。這是否存在一個問題？你配置appscan的時候你需要配置站點登陸信息，但是他解密時提交的數據本來就是你配置好的。本就是配置的數據，為什么還說你解密的？這里我對appscan的掃描存在質疑（appscan在坑人，你必須得用ssl方式訪問站點登陸！！）。
因站點的不能使用ssl方式，所以我找同事討論。得到另一個解決方案：登陸提交數據使用隱藏控件（包含登陸用戶與密碼），在提交之前對原來登陸用戶、密碼錄入框內的內容進行清空。后台判斷若錄入框內存在內容則提示“登陸操作錯誤！”。這樣配置后重新掃描，問題得到了解決，但是存在一個問題AppScan再也登陸不了系統了（掃描是會提示不能正常登陸系統，請確定登陸配置是否正確）。
DES加密及解密（js與C#配套）可參考：http://www.cnblogs.com/luowanli/archive/2013/03/08/DES-Base64%E5%8A%A0%E5%AF%86%E8%A7%A3%E5%AF%86.html
此方法能規避“已解密的登陸請求 ”的漏洞，但是不能完全解決。在實際站點中AppScan還是能掃描出此漏洞，但在掃描出的報文提交的數據中並不能查看到明文的賬號密碼信息。