Reguest: Cookies - Send To creators only

[nowshining]

I am requesting a filter that sets all cookies to be sent back ONLY to the site that first created it? IS this possible?

[Siamesecat]

Browsers are set up to send cookies back to the domain that set them, not to other domains. However, there are cookies that may be earmarked to be sent to another party, but were set by the first party host and with that hostname on them.

[nowshining]

(Mar. 04, 2009 06:37 AM)Siamesecat Wrote:  Browsers are set up to send cookies back to the domain that set them, not to other domains. However, there are cookies that may be earmarked to be sent to another party, but were set by the first party host and with that hostname on them.

yes, but I'd like to FORCE the mark.... so can a filter be made to do this...?

[Oddysey]

shiner;

AFAIK, there is no "marking' of a cookie that forces the browser to keep a high level of cookie security - browsers essentially write the cookie as it was given to them by the server. That is why Siamesecat's "earmarked for other servers" works.

Being as it sees the cookie before the browser, Proxo can change the permanence of a cookie (to session-only, if desired), and it can change the content (easily done if it's in plain text), but that's it.... Proxo is changing the cookie itself - it can't tell the browser to do something with a cookie outside of those two things. (Not that I can think of, anyway.)

To have Proxo compare the name of the current session's host (\h) with the name of a cookie, or the contents thereof, would be successful only part of the time.... many servers name their cookies oddly (not using the host name), or the content may be gibberish to the uninitiated, making it very difficult to write a filter that looks for some specific text string. (Again, not necessarily the host name.) I suppose that Proxo could use global variables to track all cookies, but that gets cumbersome, to say the least. It would more-or-less duplicate what the browser is already doing, and in my book, that's not a good use of time/resources.

You might investigate third-party cookie managers.... Not sure what they can or can't do, it's just a thought.

HTH



Oddysey

[nowshining]

(Mar. 04, 2009 07:51 PM)Oddysey Wrote:  shiner;

AFAIK, there is no "marking' of a cookie that forces the browser to keep a high level of cookie security - browsers essentially write the cookie as it was given to them by the server. That is why Siamesecat's "earmarked for other servers" works.

Being as it sees the cookie before the browser, Proxo can change the permanence of a cookie (to session-only, if desired), and it can change the content (easily done if it's in plain text), but that's it.... Proxo is changing the cookie itself - it can't tell the browser to do something with a cookie outside of those two things. (Not that I can think of, anyway.)

To have Proxo compare the name of the current session's host (\h) with the name of a cookie, or the contents thereof, would be successful only part of the time.... many servers name their cookies oddly (not using the host name), or the content may be gibberish to the uninitiated, making it very difficult to write a filter that looks for some specific text string. (Again, not necessarily the host name.) I suppose that Proxo could use global variables to track all cookies, but that gets cumbersome, to say the least. It would more-or-less duplicate what the browser is already doing, and in my book, that's not a good use of time/resources.

You might investigate third-party cookie managers.... Not sure what they can or can't do, it's just a thought.

HTH



Oddysey

well that's not true - I can make a google cookie secure by inserting after the prefs number a ; and then secure and then a ; and the browser sees it as sending for secure connections only...

example:

Code:

PREF=ID=0000000000000000:LD=en:NR=10:SG=0:S=$1$qzWYm$gvQqLyB71Bcvp5ShWF1q1;expires=AtClose; path=/; domain=.google.com

to make proxo set that cookie or something like that to send to SSL connection only - one would have to just add this:

Code:

PREF=ID=0000000000000000:LD=en:NR=10:SG=0:S=$1$qzWYm$gvQqLyB71Bcvp5ShWF1q1;secure;expires=AtClose; path=/; domain=.google.com

oh do NOT incorporate that into ur proxo config (unless u'd like to test the second one - WAIT a day or two as I have more with diff. set options, etc... and have a LOT more filters that may be useful for others, esp. the google ones... the wait is until I can get my request fulfilled...

I know it's prob. possible esp. with the example I gave u, all I need is how to add it uni or with the google one if I have to do them manually if it does NOT work as that's fine, but I need either someone else to figure it out that is SMARTER THAN I or get the right place and word to put as I searched on google and I can't fine the exact thing unless it's httponly of which I highly doubt, but could be wrong...

[lnminente]

Well i supose you know how to write filters for this, but maybe you need some tool for doing some testing.

Anyway for the example you posted we could use \1(;expires*)\2 to be replaced for \1;secure\2
The tool: CS Lite for Firefox. With it you can edit the stored cookies, play with them, and later write the corresponding filter for proxomitron

edit: link updated to english version

[nowshining]

(Mar. 05, 2009 12:26 AM)lnminente Wrote:  Well i supose you know how to write filters for this, but maybe you need some tool for doing some testing.

Anyway for the example you posted we could use \1(;expires*)\2 to be replaced for \1;secure\2
The tool: CS Lite for Firefox. With it you can edit the stored cookies, play with them, and later write the corresponding filter for proxomitron

I seen nowhere u can edit cookies with this add-on, all this add-on does it allow/block cookies from site to site, unless I missed something..

[lnminente]

Right click in his status bar icon and "Edit cookies". It's the third option in my spanish version

ONE THING:
If you are planning to write a filter for Set-Cookie, i would recommend you better to write a Cookie filter.
I explain it better, Set-Cookie is to write a cookie, but them can also be written by javascript. So better filter all the cookies (javascript or set-cookie) when them are sent (so outgoing header Cookie).

Someone correct me if i'm wrong

[nowshining]

(Mar. 06, 2009 11:50 AM)lnminente Wrote:  Right click in his status bar icon and "Edit cookies". It's the third option in my spanish version

ONE THING:
If you are planning to write a filter for Set-Cookie, i would recommend you better to write a Cookie filter.
I explain it better, Set-Cookie is to write a cookie, but them can also be written by javascript. So better filter all the cookies (javascript or set-cookie) when them are sent (so outgoing header Cookie).

Someone correct me if i'm wrong

I see now - I guess I did NOT see it on my windows box, but once installing it on my Linux box- i can see it now...and the link was for the spanish version - I got the ENGLISH one

http://rds.yahoo.com/_ylt=A0oGkjLacrFJ7f...addon/5207


edit by admin - https://addons.mozilla.org/en-US/firefox/addon/5207

[lnminente]

Sorry, i forgot to change the link for the english version, now fixed

Note: I guess you was answering me, no need to quote the full message hehe :P

[Siamesecat]

(Mar. 06, 2009 11:50 AM)lnminente Wrote:  ONE THING:
If you are planning to write a filter for Set-Cookie, i would recommend you better to write a Cookie filter.
I explain it better, Set-Cookie is to write a cookie, but them can also be written by javascript. So better filter all the cookies (javascript or set-cookie) when them are sent (so outgoing header Cookie).

Someone correct me if i'm wrong

It is best to write both. If some cookies sneak through because Prox is not watching all the possible types of server headers for cookies, or the Javascript filter did not catch all of them, you can stop them from getting out. On the other hand, why keep a lot of junk cookies that you do not want? By filtering incoming, you at least keep the junk to a minimum.

[Oddysey]

(Mar. 04, 2009 09:19 PM)nowshining Wrote:  

(Mar. 04, 2009 07:51 PM)Oddysey Wrote:  ......
Being as it sees the cookie before the browser, Proxo can change the permanence of a cookie (to session-only, if desired), and it can change the content (easily done if it's in plain text), but that's it.... Proxo is changing the cookie itself - it can't tell the browser to do something with a cookie outside of those two things. (Not that I can think of, anyway.)

well that's not true - I can make a google cookie secure by inserting after the prefs number a ; and then secure and then a ; and the browser sees it as sending for secure connections only...

example:

Code:

PREF=ID=0000000000000000:LD=en:NR=10:SG=0:S=$1$qzWYm$gvQqLyB71Bcvp5ShWF1q1;expires=AtClose; path=/; domain=.google.com

......

Err, not to rock the boat, but you've changed the content of the cookie, giving Google something to deal with, vis-a-vis how their server handles the ensuing connections. Not the same thing as your original request, so my statement stands. With your permission, of course.



Oddysey

[whenever]

(Mar. 06, 2009 11:50 AM)lnminente Wrote:  ONE THING:
If you are planning to write a filter for Set-Cookie, i would recommend you better to write a Cookie filter.
I explain it better, Set-Cookie is to write a cookie, but them can also be written by javascript. So better filter all the cookies (javascript or set-cookie) when them are sent (so outgoing header Cookie).

Someone correct me if i'm wrong

javascript could be also used to read cookies, so outgoing cookie header filter is not enough

[Siamesecat]

(Mar. 07, 2009 01:10 PM)whenever Wrote:  javascript could be also used to read cookies, so outgoing cookie header filter is not enough

That is one reason why I really like Firefox. I am able to stop it from allowing Javascript to read cookies.

[lnminente]

I found this web: http://www.quirksmode.org/js/cookies.html

Maybe is sufficient disabling the document.cookie function. So in the first script we add to every web page maybe we could add a line similar to
document.cookie = return(1);

PLEASE, SOMEONE CONFIRM THE ABOVE LINE