Portal Starter Kit - Security Concerns

[eridgway]

Hello,

Been working on a project using the Portal Starter Kit. Just about
ready to "go-live" when the bossman asks me "how safe is it". A vague
question at best, I know, but here's what I'd like to know to make
sure I'm covered when I say "pretty darn secure"

1) Has there been any instances of people being able to access
sections of the site w/o a role being assigned (or being logged in)?
2) Has anyone known of someone being able to impersonate a valid login
w/o actually logging in?

3) Has anyone succeeded in being able to change content w/o being
logged in?

...ok, so really that's just one big impersonation concen.

Here's what I've done to help out with this:

Code
* Removed all the default groups (Admin, etc).
* The login page (and all pages after that) are SSL secured
* Implemented a complex password scheme
* All data access is through stored procs (no open ended SQL)

IIS
* Moved root dir out of default location
* changed the generic IIS user account
* no FP extensions
* no FTP access
* killed the remote admin pieces
Any other steps that should be taken to help lock it down? I feel
pretty good about it, but am fairly new to .NET and would love any
feedback.

Thanks,

Eric

[Scott Allen]

Hi Eric:

One other place you might want to ask is in the asp.net forums:
http://asp.net/forums/Default.aspx?tabindex=0&tabid=1

I think they have more discussion about the starter kits over there.

--
Scott
http://www.OdeToCode.com

On 8 Sep 2004 18:02:50 -0500,
er**********@rvkuhns-dot-com.no-spam.invalid (eridgway) wrote:

Hello,

Been working on a project using the Portal Starter Kit. Just about
ready to "go-live" when the bossman asks me "how safe is it". A vague
question at best, I know, but here's what I'd like to know to make
sure I'm covered when I say "pretty darn secure"

1) Has there been any instances of people being able to access
sections of the site w/o a role being assigned (or being logged in)?
2) Has anyone known of someone being able to impersonate a valid login
w/o actually logging in?

3) Has anyone succeeded in being able to change content w/o being
logged in?

..ok, so really that's just one big impersonation concen.

Here's what I've done to help out with this:

Code
* Removed all the default groups (Admin, etc).
* The login page (and all pages after that) are SSL secured
* Implemented a complex password scheme
* All data access is through stored procs (no open ended SQL)

IIS
* Moved root dir out of default location
* changed the generic IIS user account
* no FP extensions
* no FTP access
* killed the remote admin pieces
Any other steps that should be taken to help lock it down? I feel
pretty good about it, but am fairly new to .NET and would love any
feedback.

Thanks,

Eric

[TJS]

I use the portal starter kit and know of no security holes. the steps you
may wish to add in addition to those already mentioned is to
--remove the database connection string from the web.config file or encrypt
it if stored there.
--encrypt the url string so no one can try to hack their way in through that
door

you can also look here for additional ideas from this guy

http://www.aspkey.net/aspkey/_servic...Assemblies.asp


"eridgway" <er**********@rvkuhns-dot-com.no-spam.invalid> wrote in message
news:41********@Usenet.com...

Hello,

Been working on a project using the Portal Starter Kit. Just about
ready to "go-live" when the bossman asks me "how safe is it". A vague
question at best, I know, but here's what I'd like to know to make
sure I'm covered when I say "pretty darn secure"

1) Has there been any instances of people being able to access
sections of the site w/o a role being assigned (or being logged in)?
2) Has anyone known of someone being able to impersonate a valid login
w/o actually logging in?

3) Has anyone succeeded in being able to change content w/o being
logged in?

..ok, so really that's just one big impersonation concen.

Here's what I've done to help out with this:

Code
* Removed all the default groups (Admin, etc).
* The login page (and all pages after that) are SSL secured
* Implemented a complex password scheme
* All data access is through stored procs (no open ended SQL)

IIS
* Moved root dir out of default location
* changed the generic IIS user account
* no FP extensions
* no FTP access
* killed the remote admin pieces
Any other steps that should be taken to help lock it down? I feel
pretty good about it, but am fairly new to .NET and would love any
feedback.

Thanks,

Eric

[eridgway]

Thanks for the pointers folks.

In regards to the encryption of the QS values, I actually switched the
site over to use server.transfer for all the data entry pages to keep
that data hidden as well.

Anyone else have thoughts on this?