Re: Problem with control hosted in IE

From: bogdanutz (bogdanc_at_teamnet.ro)
Date: 10/07/04

  • Next message: otto: ".NET Applications and code access security" 
    Date: Thu, 7 Oct 2004 09:25:46 +0300

    > The default .NET CAS policy only allows a Windows Forms control such as
    > yours to retrieve the default credentials if the control is loaded from
    the
    > intranet zone.

    I wasn't aware of this policy. (i guess it's about EnvironmentPermission the
    code should have)

    OK I got it. Threre are ways around this.

    10x a lot.

    "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
    news:u#5rCFArEHA.1160@tk2msftngp13.phx.gbl...
    > "bogdanutz" <bogdanc@teamnet.ro> wrote in message
    > news:uoL1OI7qEHA.896@TK2MSFTNGP12.phx.gbl...
    > <snipped>
    > > It seems natural to me that if i have an internet explorer session in
    wich
    > > i'm
    > > authenticated to a web site anything that runs in that browser context
    > > should
    > > be able to connect to site (that's assuming that the web service from
    the
    > > control is passing through the browser).
    >
    > It would if it were indeed passing through the browser, but it's not.
    > Instead, you're making a separate http request via your control.
    >
    >
    >
    > > My point is that any control loaded in internet explorer has access to
    > > DefaultCredentials (wich are also used
    > > for authentication to some web sites with integrated security).
    >
    > The default .NET CAS policy only allows a Windows Forms control such as
    > yours to retrieve the default credentials if the control is loaded from
    the
    > intranet zone. If your control were loaded from the internet zone, it
    would
    > not be able to use the default credentials. It is a potentially risky
    > operation that less trusted code is not allowed to perform.
    >
    >
    > > So why is
    > > accessing the credentials from
    > > the browser any worse than accessing the credentials from the local
    > > machine?
    >
    > In some ways, it's not. The scope and type of potential damage differs
    > somewhat, but exposing either set of credentials does pose a risk.
    However,
    > one would have to guess that use of the Windows logon credentials ended up
    > enabled by default for intranet use for some sort of non-"whoops" reason.
    > Could be something as simple as a bunch of large enterprise customers
    > wanting it this way because of their peceived internal needs.
    >
    > >
    > > I promise this is the last one.
    > > 10x a lot.
    > >
    > > PS: also are u from Romania( Calinoiu ?)
    >
    > The name is, but I'm not.
    >
    > >
    > > "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in
    message
    > > news:e4ohRH6qEHA.3748@TK2MSFTNGP09.phx.gbl...
    > >> "bogdanutz" <bogdanc@teamnet.ro> wrote in message
    > >> news:OLDTQT3qEHA.1152@TK2MSFTNGP11.phx.gbl...
    > >> > 10x for responding.
    > >> >
    > >> > It's dissapointing that i can not access those credentials. I have
    some
    > >> > questions though:
    > >> >
    > >> > 1. Why is it a security vulnerability to access those: I have access
    > >> > to
    > >> > the
    > >> > DefaultCredentials so
    > >> > what damage could be done by accessing those from IE.
    > >>
    > >> > 2. When a control loads in IE, an application domain is created with
    > >> > the
    > >> > evidence
    > >> > of the security zone from wich the code originated but without any
    > >> > knowledge
    > >> > of the security
    > >> > level of the assembly that will be loaded - that i can understand ...
    > > but
    > >> > why doesn't the application domain
    > >> > get from ie some knowledge of the user ?
    > >>
    > >> It does. The user context is that of theWindows user on the client
    > > machine
    > >> since this is the user context in which IE is running. The credentials
    > >> provided in http requests to the web server have no effect whatsoever
    on
    > > the
    > >> user context on the client machine. They are simply pieces of data
    that
    > > are
    > >> sent over the wire to another machine.
    > >>
    > >>
    > >> >
    > >> > 10x
    > >> >
    > >> > "Nicole Calinoiu" <ngcalinoiu REMOVETHIS AT gmail DOT com> wrote in
    > >> > message
    > >> > news:e$C5xowqEHA.2340@TK2MSFTNGP11.phx.gbl...
    > >> >> The control is running on the client machine, so the default
    > > credentials
    > >> > are
    > >> >> taken from the client context. These will be the Windows logon from
    > > the
    > >> >> client machine, not the credentials you entered into IE for use when
    > >> > sending
    > >> >> HTTP requests to the server.
    > >> >>
    > >> >> Basically, there is no way to read the cached IE credentials from
    > > within
    > >> >> your control (it would be a fairly big security vulnerability if you
    > >> > could),
    > >> >> so you'll need to choose an alternate approach such as one of the
    > >> > following:
    > >> >>
    > >> >> 1. Make a separate credentials request to the user from within your
    > >> >> control, then use these credentials when communicating with the web
    > >> > service.
    > >> >>
    > >> >> 2. If you're in an intranet or extranet scenario, allowing access
    by
    > >> >> appropriate domain accounts (which would be the client-side Windows
    > > login
    > >> >> accounts) may be a possibility.
    > >> >>
    > >> >> 3. Re-design this piece of the application so that the
    communication
    > >> >> between client and server would be a bit less cumbersome. One
    > >> >> possibility
    > >> >> might be use of a stand-alone Windows Forms client to communicate
    with
    > >> >> the
    > >> >> web service. Another might be removing the Windows Forms portion
    > >> >> entirely
    > >> >> and using a plain old web UI.
    > >> >>
    > >> >> HTH,
    > >> >> Nicole
    > >> >>
    > >> >>
    > >> >>
    > >> >> "bogdanutz" <bogdanc@teamnet.ro> wrote in message
    > >> >> news:OajIVltqEHA.536@TK2MSFTNGP09.phx.gbl...
    > >> >> >I have a windows control that resides in a strong named assembly.
    The
    > >> >> > assembly has the AllowPartialyTrustedCallers attribute.
    > >> >> > On the server the dll that contains the control is in a virtual
    > >> > directory
    > >> >> > that also contains a webService.
    > >> >> > The virtual directory's authentication is windows (as the
    > >> > application's -
    > >> >> > i'm using impersonation).
    > >> >> >
    > >> >> > The windows control is embeded in a page with the "object" tag.
    > >> >> > I logon to another machine using a local account (not one that the
    > > IIS
    > >> >> > could
    > >> >> > now).
    > >> >> > When i request this page from that machine IE request that i give
    > >> >> > him
    > > a
    > >> >> > windows account name and password and after that
    > >> >> > the internet explorer loads the assembly just fine, but when
    trying
    > > to
    > >> >> > access the web service mentioned eralier
    > >> >> > IIS returns a security exception (401).
    > >> >> >
    > >> >> > Before calling any method of the web service , i set the web
    > > service's
    > >> >> > credentials to System.Net.CredentialCache.DefaultCredentials.
    > >> >> > Upon inspecting the server's event log, under security, i found a
    > >> > "Failure
    > >> >> > Audit":
    > >> >> >
    > >> >> > Logon Failure:
    > >> >> > Reason: Unknown user name or bad password
    > >> >> > User Name: Administrator
    > >> >> > Domain: VM_2KPRO_GOL
    > >> >> > Logon Type: 3
    > >> >> > Logon Process: NtLmSsp
    > >> >> > Authentication Package: NTLM
    > >> >> > Workstation Name: VM_2KPRO_GOL
    > >> >> > Caller User Name: -
    > >> >> > Caller Domain: -
    > >> >> > Caller Logon ID: -
    > >> >> >
    > >> >> > The logon failure refers to the name "Administrator" , the local
    > >> >> > account
    > >> > I
    > >> >> > used to logon to the machine, not the one I gave to IE.
    > >> >> > The documentation refering to
    > >> >> > System.Net.CredentialCache.DefaultCredentials
    > >> >> > says that it will USUALLY(?) give the windows
    > >> >> > credentials.
    > >> >> >
    > >> >> > So,what is the problem , is there another way to access the
    service
    > >> >> > with
    > >> >> > windows authentication?
    > >> >> >
    > >> >> > (I tried also with anonymus access on IIS and the web service and
    > > forms
    > >> >> > authentication for the app but the cookie is not sent along with
    the
    > >> >> > request
    > >> >> > for the web service
    > >> >> > so there is no way for me to authenticate the user)
    > >> >> >
    > >> >> > Thanx
    > >> >> >
    > >> >> >
    > >> >>
    > >> >>
    > >> >>
    > >> >>
    > >> >
    > >> >
    > >>
    > >>
    > >
    > >
    >
    >

  • Next message: otto: ".NET Applications and code access security"

    Relevant Pages

    • Re: The Dangers of Nanoparticles
      ... Who does research on the effectiveness of Drugs that ... My comment was simply on the credentials of the "citizen journalist." ... Mr regular medical Doctor gave me Cauduet to control high blood ... This was no herbalist but a trained Internal Medicine Doctor - ...
      (misc.news.internet.discuss)
    • Re: The Dangers of Nanoparticles
      ... My comment was simply on the credentials of the "citizen journalist." ... Mr regular medical Doctor gave me Cauduet to control high blood ... This was no herbalist but a trained Internal Medicine Doctor - ...
      (misc.news.internet.discuss)
    • Re: Propagate Credentials from Internet Explorer Host Instead of D
      ... Those are the credentials under which the control is running, ... forget that the target site may use basic authentication, ... >> since hosted controls would be able to ...
      (microsoft.public.dotnet.security)
    • Re: Problem with control hosted in IE
      ... you're making a separate http request via your control. ... If your control were loaded from the internet zone, ... not be able to use the default credentials. ... The user context is that of theWindows user on the client ...
      (microsoft.public.dotnet.security)
    • Re: older games dont work
      ... the support of my work have it and will burn a CD to me. ... and any other tips to make this game works will be great. ... Windows 95 including but not limited to: ... to map a pedal as a control ...
      (microsoft.public.windowsxp.games)
    • Quantcast