ASP.NET - Trace.axd includes Application variables
-
Be very aware of this (or maybe it's common knowledge, and somehow I missed this vital info all these years). If you accidentelly leave tracing enabled on a production site, be aware that anyone can see the details for the past xx requests. Now normally this info is fairly mundane - control hierarchy and server variables. However, if you store connection strings in the HttpContext object, they will get output in the trace!! Could be very risky. Of course normally you would use the connectionstrings helper which is available with ASP.NET 2.0 onwards, however if you have an older app, you may be doing this (e.g. when you Server.MapPath() to your local access database or something, and later upgrade to SQL server but keep the connection string in httpcontext object :~ :~)
"For fifty bucks I'd put my face in their soup and blow." - George Costanza
CP article: SmartPager - a Flickr-style pager control with go-to-page popup layer.
-
Be very aware of this (or maybe it's common knowledge, and somehow I missed this vital info all these years). If you accidentelly leave tracing enabled on a production site, be aware that anyone can see the details for the past xx requests. Now normally this info is fairly mundane - control hierarchy and server variables. However, if you store connection strings in the HttpContext object, they will get output in the trace!! Could be very risky. Of course normally you would use the connectionstrings helper which is available with ASP.NET 2.0 onwards, however if you have an older app, you may be doing this (e.g. when you Server.MapPath() to your local access database or something, and later upgrade to SQL server but keep the connection string in httpcontext object :~ :~)
"For fifty bucks I'd put my face in their soup and blow." - George Costanza
CP article: SmartPager - a Flickr-style pager control with go-to-page popup layer.
So, if you forget to turn off debugging code and do some pretty stupid stuff around your storing of connections, and some user manages to try this and figure it out, you could be in trouble if your network isn't properly secured. Subtle.
-
So, if you forget to turn off debugging code and do some pretty stupid stuff around your storing of connections, and some user manages to try this and figure it out, you could be in trouble if your network isn't properly secured. Subtle.
Paddy Boyd wrote:
forget to turn off debugging code
Yep, sloppy. Makes a stronger case for specifically scheduling code-reviews a while after initial development.
Paddy Boyd wrote:
pretty stupid stuff around your storing of connections
OK, so apart from this potential scenario, what reason would you give me for NOT storing a connection string in the application state? (Bear in mind it has to call
Server.MapPath.. soConfigurationSettings.AppSettingsis no good - and I'm talking .NET 1.1 here).Paddy Boyd wrote:
Subtle.
Yes it is. Especially for traditional ASP programmers - you just don't expect your Application variables to ever be visible to the public like that.
"For fifty bucks I'd put my face in their soup and blow." - George Costanza
CP article: SmartPager - a Flickr-style pager control with go-to-page popup layer.