Well, I guess those numbers are not that odd for anything that's connected to the internet. My site is basically a static one-pager with no possibilities for user input whatsoever and even that page gets bombarded constantly (without effect). I mean, that's just how it is on the internet these days I guess, it can be a rather hostile environment at times :-)
Op wo 9 sep. 2020 om 17:49 schreef Ken Fallon <k...@fallon.ie>: > From Ken (HPR Janitor) > > These are the numbers since 2015-02-05_06-31-06 > > Number of attacks 4,073,951 blocked > Number of links 306 blocked > > On 2020-09-09 17:35, x1101 wrote: > > I'm not a php dev, so I defer to folks that are for implementation > comments, but if this is something that we deem desirable, could we simply > have the initial processing discard any parameters that we're not > accepting, while correctly processing things we are? > > > I don't know if that's reasonable, or what ramifications it would have for > security, but It does seem common that "big sites" are appending their junk > onto outbound links (copyright/AUP/CFAA type concerns not withstanding) and > being able to accept and discard them does seem to be a way to not loose > potential inbound links. > On 9/9/2020 11:08, Ken Fallon wrote: > > From Ken (HPR Janitor) > > Hi All, > > A lot of people are new to HPR so if you haven't done so already please > read the about page, specifically > http://hackerpublicradio.org/about.php#governance > > To be clear, if the community decide to allow this extra parameters then > we will add it to the site. > > -- > > Regards, > > Ken > Fallonhttp://kenfallon.comhttp://hackerpublicradio.org/correspondents.php?hostid=30 > > > On 2020-09-09 16:45, Roan Horning wrote: > > This reminded me of an article I saw the other day on Hacker News : URL > query parameters and how laxness creates de facto requirements on the web ( > https://utcc.utoronto.ca/~cks/space/blog/web/DeFactoQueryParameters) > > While I generally fall on the side of "Why are you putting your > parameters on my URL", does a hard "NO" hurt spreading the goodness of HPR > more than it provides a security to the site? Personally I don't find many > links on socail media i want to click upon, but I would hate to lose a > potential new listener/contributor because they followed a link from > Facebook and then didn't end up where the poster originally intended. I > know this does add some overhead to the code, but I feel it is worth it in > this instance. > > Cheers, > > Roan > > > > On Wed, Sep 9, 2020 at 7:49 AM Ken Fallon <k...@fallon.ie> wrote: > >> On 2020-09-09 11:15, Cedric De Vroey via Hpr wrote: >> > Hi all, >> > >> > I'm pretty new so I'm not sure if this topic has already been discussed, >> >> >> http://hackerpublicradio.org/pipermail/hpr_hackerpublicradio.org/2020-August/014778.html >> >> > but I have noticed some weird things while trying to link to HPR .. >> > social media accounts. When I share a link on facebook pointing towards >> > my correspondent page >> > http://hackerpublicradio.org/correspondents.php?hostid=387 then the >> user >> > still ends up on Droops page (correspondent ID 1) because facebook adds >> > this >> > "&fbclid=IwAR3C2yjdET6JY9JSfLdGzlfUprlow6GoYbnkDf8noMUTS30GbLkKgLl13z8" >> > to the url and the CMS behind HPR seems unable to handle this. >> >> The weird thing is that facebook is adding a parameter to someone else's >> website url. Please ask Facebook not to sent additional query parameters >> to websites that they do not own. I know of cases where people were >> prosecuted for adding parameters like that to websites as it was >> considered a hacking attempt. >> >> > >> > What I guess is happening is that the url mapping scheme behind the >> > correspondents page can only handle 1 parameter in the url. Once you add >> > any other parameter to the url next to hostid you see the same behavior. >> > I also noticed that if hostid is missing but any other parameter is >> > there on the correspondents page url like >> > /correspondents.php?whatever=foobar then we get a funky error: >> > image.png >> > >> >> All the pages on HPR know exactly what is allowed, what format it is. We >> will accept only the parameters that we require, and nothing else. We >> treat anyone sending additional parameters as a hostile agent and log it >> as an attack, the session is deliberately delayed, and they are removed >> from my holiday card list. >> >> > If you need help debugging the code and fixing this let me know. >> >> So far there have been 253 attempts and only 1 for gclid >> >> Seriously though, if this is something that we need to support I would >> like to hear from the community on this. >> >> I'm not sure how this "feature" would sit with our community >> https://fbclid.com/ >> >> _______________________________________________ >> Hpr mailing list >> Hpr@hackerpublicradio.org >> http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org >> > > _______________________________________________ > Hpr mailing > listHpr@hackerpublicradio.orghttp://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org > > > > _______________________________________________ > Hpr mailing > listHpr@hackerpublicradio.orghttp://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org > > > _______________________________________________ > Hpr mailing > listHpr@hackerpublicradio.orghttp://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org > > > -- > Regards, > > Ken > Fallonhttp://kenfallon.comhttp://hackerpublicradio.org/correspondents.php?hostid=30 > > _______________________________________________ > Hpr mailing list > Hpr@hackerpublicradio.org > http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org >
_______________________________________________ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
