We have a strange problem when implementing sessions with ColdFusion in IE6.
After login and after a refresh on the page all the session variables are lost.
Its some kind of config in the Administrator? Could you give me some troubleshooting tips to this issue?
Thanks in advance!
I've seen this before, but it's been a long time. I remember creating a test page to dump out the cookies for the site and they'd change on every refresh. I don't remember if we ever found a solution. I want to say that the issue cleared up after another update from Microsoft, but it was so long ago I honestly don't remember.
What's happening is you're getting new values for the CFID and/or CFTOKEN cookies that CF creates and uses to keep track of the browser's state. (The web is by its nature stateless, but that's not very helpful when you need to do transactions.)
Here are some of the possible issues I've seen other people mention:
Inconsistently using www.domain.com and domain.com. The site may work either way, but unless you're using domain cookies the cookies will care
Privacy settings in IE being too restrictive
Special characters in the domain name (underscore is mentioned specifically)
Lack of P3P policy on the web server (back to the privacy settings)
As for solutions, have you tried using J2EE session variables? Some people have had success with those in solving this.
I think it is because your IE6 is not accepting cookies?
Related
I recently switched on a WAF on our public facing website. This has caused a number of false positives and I believe legitimate users are occasionally getting blocked.
Many of these false positives are being caused by values in cookies which are triggering rules but upon inspection it looks like these cookies don't belong to us or our domain...
The most baffling one I've seen is
"matchVariableName": "CookieValue:handl_url",
"matchVariableValue": "https://xxxxxxx.com/competition-terms?utm_source=hs_email&utm_medium=email&_hsenc=[removed--hash]"
A quick search on google for "handl_url" suggests that the cookie is used to store the URL that the cookie was created on, but the domain in the cookie is not our domain...
So my questions are...
what could cause a browser to post cookies across domains like this?
could this be a bugged browser or attack on the website?
does this happen commonly on public facing websites?
For reference, we use Google Tag Manager (gtm) on our site so their may be links to other sites embedded on our website but I'm pretty sure the domain in my example isn't one of them.
Thanks,
Daniel
I'm completely new to django-saml2-auth (and SAML2 with Django in general) and am trying to get it working with Microsoft ADFS.
When I hit my Django app it successfully redirects me to the federated login page, but after providing valid credentials, the app then goes into a loop where it's just flipping back and forth between my ENTITY_ID URL (which is https://myapp/saml2_auth/acs/) and a URL on the ADFS server with continually changing SAMLRequest values as a URL parameter.
The only clue I have to go on at this point is when I check my browser history, eventually one of the page titles for all this activity in the history is "SigVer Error" but after some cursory googling I'm not sure what that might mean. I saw some references to disabling signed responses at the pysaml2 level but didn't want to go too far with that without first trying to figure out if that's even the issue given the behavior I'm seeing.
Any ideas? I can share my settings if that'd be helpful but the only optional setting I'm adding is the ENTITY_ID value since that's required by ADFS.
Debugging is also a bit of a challenge since at this point even with the Django debug level set to DEBUG it isn't revealing much, so if there's debugging tips with django-saml2-auth people can share that would be much appreciated.
Since I'm new to getting Django working with SAML2 at all I'm also not married to django-saml2-auth if there's easier/better ways to do this. Thanks for any advice anyone can provide!
In case people come across this in the future, turned out to be my bad with my django-stronghold configuration.
We have been working on a gaming website. Recently while making note of the major traffic sources I noticed a website that I found to be a carbon-copy of our website. It uses our logo,everything same as ours but a different domain name. It cannot be, that domain name is pointing to our domain name. This is because at several places links are like ccwebsite/our-links. That website even has links to some images as ccwebsite/our-images.
What has happened ? How could have they done that ? What can I do to stop this ?
There are a number of things they might have done to copy your site, including but not limited to:
Using a tool to scrape a complete copy of your site and place it on their server
Use their DNS name to point to your site
Manually re-create your site as their own
Respond to requests to their site by scraping yours real-time and returning that as the response
etc.
What can I do to stop this?
Not a whole lot. You can try to prevent direct linking to your content by requiring referrer headers for your images and other resources so that requests need to come from pages you serve, but 1) those can be faked and 2) not all browsers will send those so you'd break a small percentage of legitimate users. This also won't stop anybody from copying content, just from "deep linking" to it.
Ultimately, by having a website you are exposing that information to the internet. On a technical level anybody can get that information. If some information should be private you can secure that information behind a login or other authorization measures. But if the information is publicly available then anybody can copy it.
"Stopping this" is more of a legal/jurisdictional/interpersonal concern than a technical one I'm afraid. And Stack Overflow isn't in a position to offer that sort of advice.
You could run your site with some lightweight authentication. Just issue a cookie passively when they pull a page, and require the cookie to get access to resources. If a user visits your site and then the parallel site, they'll still be able to get in, but if a user only knows about the parallel site and has never visited the real site, they will just see a crap ton of broken links and images. This could be enough to discourage your doppelganger from keeping his site up.
Another (similar but more complex) option is to implement a CSRF mitigation. Even though this isn't a CSRF situation, the same mitigation will work. Essentially you'd issue a cookie as described above, but in addition insert the cookie value in the URLs for everything and require them to match. This requires a bit more work (you'll need a filter or module inserted into the pipeline) but will keep out everybody except your own users.
my web site suddenly started to write a cookie named arp_scroll_position in Chrome.
I did not change anything on my application to make this cookie appear, which is why that is very confusing.
In other browsers however this cookie is not set. I just tested Safari, Firefox and even Chrome Canary for that.
I also see this cookie on some other (but not all) websites. So it seems sort of being randomly placed.
I wish to have a cookieless application (no cookie usage warning & respecting the privacy of my users), so this cookie that just pops up in Chrome does counteract that a bit.
So my questions are: Where does this cookie come from? How can I prevent that cookie to be set at all?
Additional info: I use Twitter Bootstrap, but some other sites using bootstrap do not have this cookie.
Old question, but in case someone else stumbles into this:
Maybe you are using a Chrome extension called "Auto Refresh Plus (arp)". It sets a cookie with that name, see source code
Deactivate the extension, delete that cookie in the developer console, and reload the page. Cookie should be gone.
I work for an e-commerce site. Part of what we do is to offer customized items to some clients. Recently some non-technical management promised that we could incorporate our check-out process into one such client's website. The only way we've figured out how to do this is by using an iframe (I know, I don't like it either). The issue is that most customers of this site are unable to check out because we use cookies to determine which custom items to display. Browsers are recognizing our cookies as third party and almost everybody has third party cookies turned off, as they should. I'm going to be shocked if the answer is yes, but is there any workaround for this? ie can the site hosting our iframe somehow supply the necessary cookie?
Try an invisible, interstitial page.
Essentially the hosting site would issue a redirect to a site within your domain, which is then free to set cookies (because at this point is is actually the first party). Then your site immediately redirects back to the hosting site. At this point your newly-created cookies will be invisible to the hosting site but visible to your iFramed page henceforth.
Unfortunately the hosting site will have to do this every time a cookie is to be updated but the double-redirect can happen so quickly they'll hardly notice. Hopefully your system only needs the cookies to be set once.
Instead of using a cookie, pass the information in the each url request as name/value pairs.
It is a bit of a pain to add the name/value to every url...I know...oh well...it will work.
I'm going to be shocked if the answer is yes, but is there any workaround for this? ie can the site hosting our iframe somehow supply the necessary cookie?
Your iframed page itself, which is the third party in this scenario, could send a P3P Cookie Policy header – some browsers then accept third-party cookies by default, whereas others (mainly Safari) will not be convinced to do so at all if not by the user manipulating the default settings themselves.
What you could also do, is pass the session id not (only) by cookie, but as a GET or POST parameter as well – f.e. under PHP this can be done quite easily by configuring the session options. You should consider if that’s worth the slightly increased risk of session stealing.
The interstitial page solution should work but it might be a lot of trouble for your hosting site, so here's another solution that will allow you to work cookieless.
Write an HttpModule that responds to the BeginRequest event, reads the querystring, and inserts corresponding cookie headers into the Context.HttpRequest object (Note: you can't use AddCookie, you have to use AddHeader, because cookies added by a module directly are disposed of before they hit your application proper). That way the hosting site can simply issue a request (within the iFrame) that contains the necessary value in the querystring, the module will convert it into a cookie (that only exists in memory, not on the wire), and your application will be deceived into thinking that there's a cookie there. No code changes required, you just need to add the module in web.config.
This only works if you are using IIS 7.0+ in integrated pipeline mode. If you're on an earlier version of IIS or if you have to run in classic mode, you'll need an ISAPI filter instead.
Ryan , John
For the Chrome v80 update with SameSite flags, want to set the samesite=none;secure for the site hosting our iframe and somehow supply the necessary samesite=none;secure cookie. We have apache 2.2 and tomcat 6 setup, so would appreciate a solution and advice on how to make it work. Currently with flag enabled the iFrame is not punching out successfully.
Thanks