Site Hacked? Very confussing

What do you mean by your own IP address? The IP address of your Linode, of your home machine, or somewhere else?

As an alternative to malicious activity, it's possible that an automated process ran at a time you weren't expecting.

@Vance:

What do you mean by your own IP address? The IP address of your Linode, of your home machine, or somewhere else?

As an alternative to malicious activity, it's possible that an automated process ran at a time you weren't expecting.
The ipaddress in the access log was that of my home computer. And, the access time for three different files on different Apache virtual domains was within seconds of each other. Now I'm wondering if my Google Chrome browser decided to take a tour of pages in it's page history???

In 7 years of using php to write mail merged bulk emails from a mysql database I've never had the scripts fire off on their own before. Looks like they didn't fire off on there own this time either but I'm real unsure what happened. I'm waiting for the other shoe to drop.

Is it possible that a network router had buffered a page request for days/weeks and when discovered, it delivered it late? My home internet provider is Centurytel and I wouldn't be shocked if that was what happened. I should really put a little user involved interlocking on those bulk email scripts.

It's very likely that Chrome saw that non-secured, GET-based resource, and decided to grab it to see if it is interesting. It does this, which is why it is so darned fast. It is also explicitly permitted to do this.

PROTIP: Never, ever, ever use a HTTP GET request to do something.

Or, put another way,

> There are four basic methods in HTTP: GET, POST, PUT, and DELETE. GET is used most of the time. It is used for anything that's safe, that doesn't cause any side effects. GET is able to be bookmarked, cached, linked to, passed through a proxy server. It is a very powerful operation, a very useful operation.

POST by contrast is perhaps the most powerful operation. It can do anything. There are no limits as to what can happen, and as a result, you have to be very careful with it. You don't bookmark it. You don't cache it. You don't pre-fetch it. You don't do anything with a POST without asking the user. Do you want to do this? If the user presses the button, you can POST some content. But you're not going to look at all the buttons on a page, and start randomly pressing them. By contrast browsers might look at all the links on the page and pre-fetch them, or pre-fetch the ones they think are most likely to be followed next. And in fact some browsers and Firefox extensions and various other tools have tried to do that at one point or another.

From what I can find, it looks like Chrome when not busy will look though it's history file and try to refresh it's cached pages. That's pretty wild.

So, yes, I need to stop my bad habits surrounding the naked get calls for my admin tasks. I should throw a login class on top of them and require a current session before they start working.

Thanks.

this reminds me of a website that provided a todo list, I can't remember the name.

It had a list of things you needed to do, and a link next to them to mark them as done, and removed them from your todo list.

One day, web browsers, or a web browser plugin, started following links on a page in the background to put them in cache, so if you clicked on a link, it would display the next page very quickly, well, peoples todo lists started disappearing, as browsers would follow the "done" link to cache them.

Another real world example of why get requests shouldn't modify data.