• Resolved Per Alm

    (@per-alm)


    Suddenly I got 2049 visitors and 2042 of them was a bad one. All 2042 had the same information. As I can see in the program file hits.class.php the visitor shall only be INSERTed to the table ones a day.

    Shouldn’t it be better to append a counter, as for excluded visitors, and try with an UPDATE of the counter before an INSERT is executed?

    But I’m still confused about why the visitor was appended so many times. I know that the visitor was a hacker trying to login. I have a back up of the sql-table.

    https://www.ads-software.com/plugins/wp-statistics/

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Contributor Greg Ross

    (@gregross)

    A visitor is only recorded once per day in the database, so no counter is required.

    For the visitor code, the logic basically comes down to looking for the record in the database that matches the date and ip address. If it’s found, there’s nothing to do as we don’t count the number of times a visitor came to the site in a given day. If it is not found, then we add it to the database.

    I’ve seen this behavior once on my own site and have not been able to track down why it happened. I suspect there was something going wrong in the database code (either the client or server side), possibly something wrong in the cached results. If a lot of hits all came in at virtually the same time, a cached result could give a false negative on finding the record in the database which would then trigger the insert multiple times.

    The best ‘solution’ I’ve come up with on this would be to add a constraint on the database table for the date/ip fields, but without a test case I’m a bit hesitant to do this.

    Thread Starter Per Alm

    (@per-alm)

    I can see that the counter is not useful normally. But the counter can be interesting for debugging or hack analysis.

    Can one be sure about that execution is not interrupted between SELECT and INSERT operations. I suppose that an UPDATE operation with “ counter = counter + 1 “ is better protected than “ counter = {$this->counter} + 1 “, with a counter value taken from the earlier SELECT operation.

    In my case I was working at the server when the skyfall occurred and I got 404-respons several times. I think that the sever was very busy by some mass login from the hacker. I had earlier seen that the hacker was a new subscriber user and therefore manipulated its password. A login should therefore not success. I did also look for the IP-user by clicking at the IP in the visitors list. May be some strange condition occurred than. I don’t know.

    Plugin Contributor Greg Ross

    (@gregross)

    I’ve looked in to several different fixes for this and the one that makes most sense is going to take a bit of work to get right on pre-existing installs.

    I’ll look to get something done in the next couple of releases.

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Skyfall of logins’ is closed to new replies.