How to fix problem-usernameTokenSecurity can be bypassed in IE

[John K]

I have usernameTokenSecurity with usernameOverTransportSecurity working in
WSE 3 and .NET 2.0 in a CustomUsernameTokenManager. It properly verifies if
someone is authorized (i.e. if user is in certain SQL database). I have also
confirmed it denies someone access if they don't have the right credentials
when invoked from a client program. The problem is the fact that this
security can be easily bypassed if the user uses Internet Explorer and
browses to the web page e.g. https://x/CS.asmx and chooses a web service
function. The web service function works and does NOT authenticate the user;
it just allows the person to use the web function. How do I force the web
service (C# 2005) to use the CustomUsernameTokenManager (AuthenticateToken)?
In other words, if someone invokes the function from a browser; the token
will be missing; how do I force the service to throw an exception if the user
name token is missing. The ability to use the web service without
authentication seems to be a fundamental violation of why WSE 3 security.
This is also the case in a Microsoft WSE 3.0 example: Web Services
Enhancements 3.0 Hands On Lab -
Security\CS\Basic\Part1\after\Part1_After.sln. Thus, even the Microsoft
example on how to use usernameTokenSecurity doesn't enforce security if the
web service is invoked via Internet Explorer.

 

[Steven Cheng[MSFT]]

Hello John,

From your description, you've used WSE 3.0 usernameOverTransport assertion
to secure your webservice, however, you found that this can not protect the
client access to the webservice from IE browser, correct?

As for this behavior, it is due to the fundamental implementation of
ASP.NET webservice's asmx test page and the WSE components. For ASP.NET
asmx's test invoke page, it only send http message rather than SOAP message
when invoke the webservice webmethod(also only webmethod with simple type
arguments can be tested through this invoke page). For WSE component, it
is designed to decorate standard SOAP message based webservice, so it won't
take effect on the webmethod invoked through the IE test page.

Actually, for product environment deployed webservice, the webbrowser test
page should be disabled since they're not comform to webservice SOAP
standard message. In ASP.NET, you can use the following configuration
elements to remove the http related protocols so as to disable such webpage
invoke interface:

=======================
<configuration>
<system.web>
<webServices>
<protocols>
<remove name="HttpGet"/>
<remove name="HttpPost"/>
<remove name="HttpPostLocalhost"/>
</protocols>
</webServices>
</system.web>
</configuration>
=========================

#<protocols> Element
http://msdn2.microsoft.com/en-us/library/ccbk8w5h.aspx

After remove those "httpGet" and "httpPostxx" protocols, client user can no
longer access the webservice through browser(the test page).

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.



Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================



This posting is provided "AS IS" with no warranties, and confers no rights.