Re: ASP Admin system pointers
am 22.06.2005 17:44:15 von Oliver Weichhold
Hi All
I've been creating a number of admin systems now for my classic ASP sites
and although they seem to keep the wolves from the door, I just wanted to
ask if you have any additional security pointers that I should watch out
for.
For your ref, the ones that I have already been told are:
a) Always have a login/password section in place and use session vars to
allow access into the protected pages. If the browser won't work with
session vars then they can't get in and the end user will have to sort it
out to get session vars to work. NOTE: my ISP charges for HTAccess
functionality so I don't use this.
b) Put login and protected pages in an obscurely named sub-directory.
c) When on the live site, make sure the pages are set to On Error Resume
Next so that no unwanted database error messages are shown to the user.
Any more?
Should I expire the pages so that web logs can't log the referrer (ie the
end user goes from the admin system to somebody's else site) and don't
appear in a web site's history? Is this actually possible?
Many thanks for any pointers you can give.
Regards
Robbie
Re: ASP Admin system pointers
am 22.06.2005 19:47:56 von Jon
I would recommend expiration especially because some people login from
public computers and this could cause quite a major security flaw.
I'm not aware of a way to prevent them from appearing in the history ...
though this doesn't mean it isn't possible.
Also the method you use to retrieve the login details may need some security
adjustments. Though with out a clue of how you do this I cannot say.
Obscurely named directories? That's a knew one to me ... Though again I'm
not doubting this just commenting :op
Wait for Mr Barrows to check and he may have some useful advice!
--
Jon
warpedpixel@gmail.com
Look at that dead pixel on your screen! *SLAP* Gotcha!
"Astra" wrote in message
news:O795$E0dFHA.2984@TK2MSFTNGP15.phx.gbl...
> Hi All
>
> I've been creating a number of admin systems now for my classic ASP sites
> and although they seem to keep the wolves from the door, I just wanted to
> ask if you have any additional security pointers that I should watch out
> for.
>
> For your ref, the ones that I have already been told are:
>
> a) Always have a login/password section in place and use session vars to
> allow access into the protected pages. If the browser won't work with
> session vars then they can't get in and the end user will have to sort it
> out to get session vars to work. NOTE: my ISP charges for HTAccess
> functionality so I don't use this.
>
> b) Put login and protected pages in an obscurely named sub-directory.
>
> c) When on the live site, make sure the pages are set to On Error Resume
> Next so that no unwanted database error messages are shown to the user.
>
> Any more?
>
> Should I expire the pages so that web logs can't log the referrer (ie the
> end user goes from the admin system to somebody's else site) and don't
> appear in a web site's history? Is this actually possible?
>
> Many thanks for any pointers you can give.
>
> Regards
>
> Robbie
>
>
>
Re: ASP Admin system pointers
am 22.06.2005 23:47:39 von Ken Jenkins
check out some of the commercial applications out there and see what sorts
of thing shtye do in their feature lists
http://www.codewanker.com/default.asp?id=21&parentID=1
http://www.aspin.com/home/webapps/usermanage
"Astra" wrote in message
news:O795$E0dFHA.2984@TK2MSFTNGP15.phx.gbl...
> Hi All
>
> I've been creating a number of admin systems now for my classic ASP sites
> and although they seem to keep the wolves from the door, I just wanted to
> ask if you have any additional security pointers that I should watch out
> for.
>
> For your ref, the ones that I have already been told are:
>
> a) Always have a login/password section in place and use session vars to
> allow access into the protected pages. If the browser won't work with
> session vars then they can't get in and the end user will have to sort it
> out to get session vars to work. NOTE: my ISP charges for HTAccess
> functionality so I don't use this.
>
> b) Put login and protected pages in an obscurely named sub-directory.
>
> c) When on the live site, make sure the pages are set to On Error Resume
> Next so that no unwanted database error messages are shown to the user.
>
> Any more?
>
> Should I expire the pages so that web logs can't log the referrer (ie the
> end user goes from the admin system to somebody's else site) and don't
> appear in a web site's history? Is this actually possible?
>
> Many thanks for any pointers you can give.
>
> Regards
>
> Robbie
>
>
>