RE: ASPState Bug/Security issue
From: Brian Gambs (nobgambsspam_at_healthshare.com)
Date: 07/29/03
- Previous message: Cash Foley: "Attempting to stop a Windows Service in a Web Application"
- In reply to: Yan-Hong Huang[MSFT]: "RE: ASPState Bug/Security issue"
- Next in thread: Yan-Hong Huang[MSFT]: "RE: ASPState Bug/Security issue"
- Reply: Yan-Hong Huang[MSFT]: "RE: ASPState Bug/Security issue"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 29 Jul 2003 14:18:22 -0700
Hi -- I am not sure what you are saying.
InstallPersistSqlState.sql will indeed "resolve" my
problem in the sense of avoiding the issue.
It doesn't really answer my question, however.
My question is: what is the proper way to configure SQL
Server security for ASP.Net state, where the state is
being stored in tempdb (InstallSqlState.sql).
My suspicion is that there is no way to install this and
configure permissions such that you can shut down and
restart sql server without having to reset permissions
and possibly reinstall the state database.
Brian
>-----Original Message-----
>Hello Brian,
>
>I checked the InstallPersistSqlState.sql file on my
side.
>
>CREATE PROCEDURE TempInsertStateItemLong
> @id tSessionId,
> @itemLong tSessionItemLong,
> @timeout INT
>AS
> DECLARE @now as DATETIME
> SET @now = GETDATE()
>
> INSERT ASPState..ASPStateTempSessions
> (SessionId,
> SessionItemLong,
> Timeout,
> Expires,
> Locked,
> LockDate,
> LockCookie)
> VALUES
> (@id,
> @itemLong,
> @timeout,
> DATEADD(n, @timeout, @now),
> 0,
> @now,
> 1)
>
> RETURN 0
>GO
>
>Did you download the persist state file at
http://support.microsoft.com/?id=311209? Thanks very much.
>
>Best regards,
>Yanhong Huang
>Microsoft Online Partner Support
>
>Get Secure! - www.microsoft.com/security
>This posting is provided "AS IS" with no warranties, and
confers no rights.
>
>--------------------
>!Content-Class: urn:content-classes:message
>!From: "Brian Gambs" <nobgambsspam@healthshare.com>
>!Sender: "Brian Gambs" <nobgambsspam@healthshare.com>
>!Subject: ASPState Bug/Security issue
>!Date: Thu, 24 Jul 2003 08:09:11 -0700
>!Lines: 93
>!Message-ID: <0df101c351f5$8999eef0$a401280a@phx.gbl>
>!MIME-Version: 1.0
>!Content-Type: text/plain;
>! charset="iso-8859-1"
>!Content-Transfer-Encoding: 7bit
>!X-Newsreader: Microsoft CDO for Windows 2000
>!X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
>!Thread-Index: AcNR9YmZoldjojzWS/m5bSgeW0QzwA==
>!Newsgroups:
microsoft.public.dotnet.framework.aspnet.security
>!Path: cpmsftngxa06.phx.gbl
>!Xref: cpmsftngxa06.phx.gbl
microsoft.public.dotnet.framework.aspnet.security:6008
>!NNTP-Posting-Host: TK2MSFTNGXA12 10.40.1.164
>!X-Tomcat-NG:
microsoft.public.dotnet.framework.aspnet.security
>!
>!I've been trying to figure out how to properly install
>!and configure ASPState (fwk 1.1,non-persistent, sql
based
>!state) in a way that
>!
>!a. works
>!b. doesn't require an account with system
>!administrator/sa access
>!
>!Before I begin -- I know -- and accept -- that state
>!information does not survives a sql restart unless you
>!use the persist state version. I see an upside in using
>!tempdb for storage and I'm fine with the downsides.
>!Except...
>!
>!The only thing resembling microsoft documentation that
>!even refers to setting up security for this is here
>!http://msdn.microsoft.com/library/default.asp?
>!url=/library/en-us/dnnetsec/html/THCMCh19.asp
>!
>!It suggests that one needs to grant exec access on all
>!the stored procs in aspstate and you are good to go.
>!
>!This demonstrably isn't true, totally reproducibly so.
>!You need to assign permissions in tempdb, ideally "dbo"
>!permissions.
>!
>!Okay, fine. Weird, but, at least I know what I must do.
>!
>!Unfortunately, this doesn't survive a sql server
restart.
>!If you create a login for, say "aspnet" with only the
>!default aspnet permissions, use sql integrated security
>!to give it a sqllogin, map it into an application
>!database, aspstate, and tempdb, give it exec perms in
>!aspstate and dbo rights in tempdb, then try to access
>!session state, this works.
>!
>!Restart sql sqlserver, and you fail with horrible
>!exceptions, e.g:
>!
>!"INSERT permission denied on
>!object 'ASPStateTempSessions', database 'tempdb',
>!owner 'dbo'. "
>!
>!Checking tempdb, the login for aspnet is no longer
>!present in tempdb. Presumably, tempdb is recreated on
>!restart.
>!
>!So....you need to go through a complicated dance, most
>!easily performed by dropping and recreating aspstate
db.
>!Not so cool for a production system.
>!
>!Now, checking the code for the stored procedures in
>!aspstate, one can see that they reference tempdb
>!directly, e.g.:
>!(from TempInsertStateItemLong)
>!INSERT tempdb..ASPStateTempSessions
>! (SessionId,
>! SessionItemLong,
>! Timeout,
>! Expires,
>! Locked,
>! LockDate,
>! LockDateLocal,
>! LockCookie)
>! VALUES
>! (@id,
>! @itemLong,
>! @timeout,
>! DATEADD(n, @timeout, @now),
>! 0,
>! @now,
>! @nowLocal,
>! 1)
>!
>!This strikes me as a terrible, horrible, approach to
>!accessing tempdb. Maybe this is
>!allowed/supported/endorsed now and I am unaware, but,
>!clearly, this engenders (so far as I can tell) pretty
>!severe adverse consequences if you are trying to
actually
>!allow your applications to continue WORKING after a sql
>!server restart. Again, I know I'm going to lose the
state
>!information itself. I would just like to not have to
>!reinstall databases, frantically rework security, etc.
>!
>!So, what am I missing here? For now, we are going to go
>!with the persiststate version, because it seems to be
>!pretty much identical except that instead of tempdb..
you
>!get aspstate.. which is obviously going to work...
>!
>!Any comments or help appreciated.
>!
>!Brian
>!
>!
>
>
>.
>
- Previous message: Cash Foley: "Attempting to stop a Windows Service in a Web Application"
- In reply to: Yan-Hong Huang[MSFT]: "RE: ASPState Bug/Security issue"
- Next in thread: Yan-Hong Huang[MSFT]: "RE: ASPState Bug/Security issue"
- Reply: Yan-Hong Huang[MSFT]: "RE: ASPState Bug/Security issue"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]