Member Avatar for FSNHosting

ok, I have a site that's using a signup form for people to enter a bunch of information, then I'm storing it in session variables until the final submission, when I then insert it all into the database in 1 shot. The point of this is to keep from cluttering up the database with half-entered forms and whatnot.

What I've found, when using IE7 to do the signup form, for some odd reason that I haven't been able to determine, the session value "username" (e.g. $_SESSION) keeps getting reset from what's posted from the form values to the string "iecssfix".

I have put echos into the pages to see what's in the session values, and what is being sent to the page through http post, and there's nothing in the post itself that would be doing this. I've also did a grep on the entire directory structure of the website's account, and that string does NOT appear in any file in the entire site.

Google has 0 hits for the string "iecssfix", so I'm struggling here. I've talked to 2 other developer friends, and neither of them can figure out where the hell it's coming from either.

This only happens with IE of course, but it has to be supported on this site, so I'm lost... has *anyone* ever seen this?

Thanks

  • 4 Contributors
  • 4 Replies
  • 112 Views
  • 3 Days Discussion Span
  • Latest Post Latest Post by digital-ether

Dani AI

Generated

reported an IE7-only problem where a session field was being replaced by an unexpected string. flagged checking IE cookie/privacy behavior and asked whether the overwrite happens on the client request or inside the server response. Below are focused, practical steps to isolate the fault and a quick hardening fix so the app is safe while you hunt the root cause.

First, determine where the value appears: capture the raw HTTP traffic from the IE7 client (use a proxy like Fiddler). Reproduce the signup flow and inspect the POST body and the Set-Cookie headers. If the bad value arrives in the POST, the problem is being introduced client-side (injected DOM/toolbar/proxy). If not, it’s being assigned server-side — trace server code paths that touch the session. Add short server logs that dump POST and SESSION before and after the session writes so you can see which request/line makes the change:

error_log("POST: " . json_encode($_POST));
error_log("SESSION before: " . json_encode($_SESSION));
/* perform the code that writes session */
error_log("SESSION after: " . json_encode($_SESSION));

Client-side culprits to test quickly: run IE without add-ons (safe mode / -extoff), test from a different network (to rule out a proxy or ISP filter), and view the raw HTML response to search for the offending string — toolbars or middleboxes sometimes inject CSS/JS or hidden fields. Inspect the live DOM with developer tools to see if any script injects or mutates form elements before submit.

Immediate mitigation: stop copying every incoming POST key into session blindly. Use an explicit whitelist of expected fields and reject anything unexpected. That both prevents accidental overwrites and makes debugging easier. Also ensure session_start() runs at the top of each request and review session cookie settings; PHP session behavior is documented at PHP session_start. If these steps don’t reveal the cause, post trimmed Fiddler captures and sanitized server logs so others can spot whether the change is client- or server-originated.

Recommended Answers

All 4 Replies

Member Avatar for mikeandike22

You might actually have to post the script or at least part of the script. and from what I can gather from your post the username and password isnt being stored when you go onto other pages or something like that. You might want to try using cookies or something like that. However that might not be your problem your question is kind of vague

Member Avatar for FSNHosting

You might actually have to post the script or at least part of the script. and from what I can gather from your post the username and password isnt being stored when you go onto other pages or something like that. You might want to try using cookies or something like that. However that might not be your problem your question is kind of vague

The username and password are being set to session variables as each page loads. For example, when values are posted to the page from the form, I've got a loop in there that takes each posted value, and sets it to a corresponding $_SESSION value. Like so:

foreach($_POST as $key => $value) {
        if(!empty($value)) {
            $_SESSION[$key] = $value;
        }else{
            $_SESSION[$key] = "none";
        }
}

I will also mention that this problem only appears in IE 7, as I've tested the page in Firefox, Opera, and IE 6 without this issue appearing.

As I stated in the original post, I've got print_r functions in the page header to echo out the values of the session and post variables as the steps are gone through, and IE 7 is the only place this happens. There's nothing in the subsequent $_POST values that would be resetting it in any way.

Member Avatar for MattEvans

have you checked the IE7 security settings? I'm assuming "SESSION" is represented by cookies... IE7 has some pretty funky cookie rules...

Member Avatar for digital-ether

Where exactly is $_SESSION being reset? Have you figured that out...

Is is in the subsequent HTTP request made by IE7 or is it changed in the first HTTP response when the cookie was set?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.