關於我的這個question，我得到了以下答案，將其添加到Web配置文件中。它也解決了我面臨的問題。但現在我的問題是，是否有任何形式的安全威脅？如果是的話，可能會有多嚴重？它可能是什麼樣的威脅？你在這裏建議別的嗎？我可以使用Web服務面對哪種安全威脅？
<configuration>
<system.web>
<webServices>
<protocols>
<add name="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>
</system.web>
</configuration>
默認情況下禁用HttpGet和HttpPost的原因是您可以輕鬆地將其用於XSS攻擊。來自http://msdn.microsoft.com/en-us/library/ff648667.aspx：
通過禁用不必要的協議，包括HttpPost和HttpGet，可以減少攻擊面積。例如，外部攻擊者可能會在電子郵件中嵌入惡意鏈接，以使用最終用戶的安全上下文執行內部Web服務。禁用HttpGet協議是一種有效的對策。在很多方面，這與XSS攻擊類似。這種攻擊的一種變體使用可公開訪問的網頁上的標籤將GET調用嵌入到Intranet Web服務中。這兩種攻擊都可以讓外人調用內部Web服務。禁用協議可以降低風險。
有關XS攻擊的更多信息，請參見http://en.wikipedia.org/wiki/Cross-site_scripting。
我通常避免使用HttpGet和HttpPost是可能的。如果它是以任何方式管理金錢的網絡服務，我不惜一切代價避免它。儘可能使用SOAP Web服務。
一般來說，當你實現一個基本的SOAP Web服務時，你將服務暴露給世界，無論好壞。您在代碼中必須考慮的主要問題是驗證輸入。天真地接受字符串可能會非常有害。如果有任何值可能是您無法處理的數字，請查找它並且不要繼續。如果你接受字符串，確保你徹底清理它們（尋找和非常懷疑分號，並逃脫你看到的每一個「特殊字符」）。
對於在SQL查詢中使用unsanitized字符串的天真服務的常見攻擊可能看起來像「ABC」; drop database master;「。如果你的代碼注入到SQL查詢中而沒有注意到僞造的查詢終止和惡意腳本，你可能在第二天清理你的桌面。解決方案非常簡單;轉義單引號，用ASCII或Unicode表示法替換分號，您可以將其翻譯回來（或簡單地將其除去），並且服務調用將它視爲垃圾。
這提出了第二點;即使它們是你的代碼，你的Web服務也應該成爲你係統其他部分非常懷疑的主題。 Web服務應該使用DB身份驗證，它提供儘可能少的權限來完成他們的工作。如果您的服務使用管理員或DBO登錄，則幾乎肯定是錯誤的;上面的查詢，如果它通過，實際上會被執行，並且您的主數據庫不再能夠使您的數據庫服務器無法運行。如果你的服務使用了一個非常嚴格地將權限控制在服務所需要的權限的登錄名，那麼SQL Server會陷入困境，但是這比失去你的主數據庫要好得多。
另外，要非常小心異常處理。通過SOAP返回的形式很差的異常，就像一個有效的結果一樣，可能包含機密信息，鼓勵攻擊者嘗試讓您的服務拋出一個異常，其中包含有關服務背後實現的有用信息。 SQL/ADO例外對攻擊者特別有用，因爲它們提供了可能被利用來造成麻煩的數據結構信息。尋找可能會導致無法控制的異常的事情，並在CLR或其他層比代碼更深的層次之前優雅地處理這種情況。捕獲所有異常在其他地方通常是不好的做法，但是在某些情況下，帶有一些消毒功能的「catch-and-release」可能是一個好主意，而通常指示異常陷阱的非常通用的500錯誤重定向在webosphere中是很常見的做法。如果您想要或必須在代碼中拋出異常，請仔細製作它，並且不要包含任何您不希望世界知道的信息。
從建築的角度來看，想想你的服務就像牆上的電源插座。插頭是讓你想要的東西（電源）離開牆壁的唯一途徑。你知道有J-box，導管，開關等，但是如果沒有很多（文字）黑客攻擊，你就無法訪問它們。按照這個比喻，你的端點應該被設置爲在指定的已知端口上進行監聽，而系統的其他部分應該看起來像從外面看到的牆;所有其他港口應該關閉。
我想你應該遷移到基於WCF的Web服務。除了WCF對asmx的所有其他好處之外，WCF 4還具有基於HTTP Accept頭的自動響應格式選擇（json或xml），或者與請求消息格式不同。
一般來說，如果你有面向公衆的網絡服務，那麼DOS攻擊是你應該擔心的。在最壞的情況下，它可能會導致你的服務崩潰，最好它會拒絕你的WS的合法呼叫者。格式錯誤的SOAP消息，XML bombs可用於DOS攻擊。
Web服務威脅我的狗一次.. – 2010-09-01 16:12:10