May 2008 - Posts
There seems to be a number of SQL injection attacks happening lately involving adding of <script src=http://www.banner82.org/b.js></script>, adword71.com/b.js
(and the likes ) to entries under string/text/varchar columns in the
database targetting ASP (classic/3.0) sites and SQL Server. Note, they
need not know your table or column names to mess up with you.
I definitely do not wish to play cops and robbers here but I wish to
contribute a little on this. There are a number of articles on this
(read along) and even more for preventing
SQL injection and other related exploits such as cross-site scripting
so help yourself.
As mentioned this is more targeted to ASP (classic/3.0) sites but posting nevertheless.
Read full article from Security alert : SQL injection attacks - banner82 script
Thanks to Robert Robbins post on rising SQL injection threats for making me think of cross posting here in weblogs.asp.net. I agree that this threat could be eliminated better with help/information from the community (if not MSFT itself)
You might encounter a case where updating an ASP (classic/3.0) cookie from ASP.NET code (or vice versa) doesn't work. That is despite updating the cookie value, the old value still remains.
I was working on a having an ASP page communicate some information to
an ASP.NET (2.0) page and vice versa and since the information was not
that critical/confidential a cookie would do (** for
critical information, it is usually done using a common
datastore/database or session though that not secure. will not discuss
here for now). I expect it to be seamless since they're accessing the
same set of cookies after all. However to my surprise it was acting
weird.
After a review of some code and I was certain that each of them
updates the cookie correctly, it was time to bring up fiddler (or any
cookie viewer) and it's when I started getting more clues.
Turns out that the case is actually not "not being updated" but rather a new cookie is created with the same key because of differences in handling cookie paths which must be the same across ASP and ASP.NET for them to talk about the same cookie (using the same name).
Read full article in the following link : Updating ASP cookie from ASP.NET (vice versa)
I ran into this behavior (which I think is weird) where a button no longer posts back to ther server after I click on a the Firefox's back button.
I'm not sure if I'm missing some incorrect settings whatsoever but it works on IE7. I'm hoping someone who runs into this might verify or some thoughts on why is behaves that way. Using Firefox 2.0.0.14, ASP.NET 2.0
Here is my code
ASPX (sorry no formatting but it's just a simple page with an ASP button)
<%@ Page AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" Language="C#" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head id="Head1" runat="server">
<title>Untitled Page</title>
</head>
<body>
<form id="form1" runat="server">
<div>
<asp:Button ID="Button1" runat="server" OnClick="Button1_Click" Text="Button" UseSubmitBehavior="false" /></div>
</form>
</body>
</html>
Code behind
1 using System;
2 using System.Web.UI;
3
4 public partial class _Default : Page
5 {
6 protected void Page_Load(object sender, EventArgs e)
7 {
8 //if (Request.Browser.MSDomVersion.Major == 0) // Non IE Browser?
9 // Response.Cache.SetNoStore(); // No client side cashing
10 }
11
12 protected void Button1_Click(object sender, EventArgs e)
13 {
14 Response.Write(Guid.NewGuid());
15 }
16 }
1. Load the page
2. Click on the button. Click event handler in server side runs and a GUID is displayed after page reloads
3. Click Back button. As far as my machine/browser behaves, no postback happens.
On the other hand, if using IE (7), step 3 still causes a postback.
It does seem that it has something to do with client side caching since if you uncomment the code in Page_Load, step 3 causes a postback. The only difference with IE though is that if say you have a textbox in the same page, you place some text in the textbox and you click the back button since no client side caching is made, you loose the contents of the textbox.
Installed FireBug to get some hint but for some reason it caused some intermittent behavior. Sometimes it works (posts back) sometimes it doesn't. Not sure though if it's FireBug causing the intermittent behavior but the "no postback behavior" predates the FireBug installation.
Haven't got the chance to dig deeper into this yet. Gotta get back to work :) I hope I'm just not missing something obvious here...
Resources:
Prevent client caching in browsers other that Internet Explorer
__doPostBack and the Back Button by Rick Strahl - some possibly relevant information but not quite since in his case, the button click and checkbox check changed event both fire in the server side, in my case the page doesn't postback at all.
Just a quick note. I was working on some Web User Control and needed to
persist information across postbacks and thought of using ViewState.
But while I was working on it, I realized that I was using the same key
for saving another information in the parent Page's (the Page
containing the user control) ViewState.
I did a little verification and it turns out that despite having the
same key being used for saving different values to ViewState, having it
assigned inside the Web User Conrol and inside the Page results to two
different ViewState items. I verified by assigning ViewState to
the Page's and the User Control's Page_Load event handler, then since
the user control's page load fires later than the two, placed a
breakpoint after it, checked the ViewState (while inside the User
Control code) and it returned the value assigned inside it, while
calling Page.ViewState and the same key, it retrieved the value that
was previously assigned from the Page_Load of the parent Page.
This is the behavior as far as my little test has shown but feel
free to verify in your machine and let us know how it goes especially
if the behavior is different from above. Haven't come across an explanation yet but will update this as soon as I can or maybe could stumble upon and comment. :) Nevertheless just FYI.
This is not to be confused with Control State which is discussed more clearly from the links below:
Control state in ASP.NET 2.0 by Fritz Onion (PluralSight)
Control State vs. View State Example on MSDN
ControlState Property Demystified
Cross post from : .NET Developer Notes on Page ViewState, Control ViewState and ControlState
More Posts