Re: [Hpr] HPR urls doing weird things

[Bob Jonkman]

If the injected URL parameters should happen to collide with an accepted 
parameter, then there could be unpredictable results.  For example, if 
HPR accepted the "Friends Being Cool Listeners In December" parameter:


http://hackerpublicradio.org/correspondents.php?hostid=387&fbclid=bobjonkman

but then Facebook appends another fbclid parameter and who knows what 
would happen...



It is likely that Facebook's parameter encodes personally identifiable 
data. The danger to privacy comes when someone copies the URL from 
Facebook on another site that gathers Facebook stats. Now that other 
site has information on who originally posted the link, and possibly who 
copied it, and from 'referer' data, where it was posted to, and how 
often it gets clicked on.


I think HPR's current behaviour (treat invalid parameters as an attack) 
is correct, even if a bit drastic. Perhaps a more explanatory error 
message would help educate people about this privacy issue, eg. "412 
Precondition Failed: The URL submitted contained invalid data, likely 
added by commercial social media to track personal information. To 
protect privacy, HPR rejects this URL."


--Bob.


On 2020-09-09 6:10 p.m., Cedric De Vroey via Hpr wrote:

Op wo 9 sep. 2020 om 23:55 schreef Kevin O'Brien :


Wouldn't accepting parameters from others pose a security problem? I tend
to think it expands the attack surface.



No it doesn't really, as long as you use named parameters, and as long as
you implement proper sanitation on those parameters you should be fine from
a security perspective. However, there are privacy concerns that could be
made over this practice since it could be used to track users.




Regards,


--
Kevin B. O'Brien
z wil...@zwilnik.com
http://google.me/+kevinobrien
http://www.google.com/profiles/Ahuka5656
http://about.me/zwilnik
“People shouldn't be afraid of their government. Governments should be
afraid of their people.” - Alan Moore, *V for Vendetta*
*Public Key = F6283E7A *



On Wed, Sep 9, 2020 at 12:13 PM Ken Fallon  wrote:


On 2020-09-09 18:10, Cedric De Vroey via Hpr wrote:

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 :-)


Actually that's the ones that make it through Joshes bear traps ;-)

--
Regards,

Ken Fallon
http://kenfallon.com
http://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




___
Hpr mailing list
Hpr@hackerpublicradio.org
http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org



--
Bob Jonkman   Phone: +1-519-635-9413
SOBAC Microcomputer Services http://sobac.com/sobac/
Software   ---   Office & Business Automation   ---   Consulting
GnuPG Fngrprnt:04F7 742B 8F54 C40A E115 26C2 B912 89B0 D2CC E5EA




___
Hpr mailing list
Hpr@hackerpublicradio.org
http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org

Re: [Hpr] HPR urls doing weird things

[Roan Horning]

On Thu, Sep 10, 2020 at 10:16 AM Ken Fallon  wrote:

> On 2020-09-10 16:08, Roan Horning wrote:
>
> > Would a more generic
> > solution be to modify the sanitize function to just drop invalid
> > parameters, log as potential attack, and then do a redirect from php
> > with just the valid parameters, or just show the page using the
> > validated parameters?
> >
>
> I would perfer to focus our energy on going to flat file format. That
> way anyone can send whatever they like because it will be basic html
> they get.
>

That would certainly solve the issue :)
___
Hpr mailing list
Hpr@hackerpublicradio.org
http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org

Re: [Hpr] HPR urls doing weird things

[Ken Fallon]

On 2020-09-10 16:08, Roan Horning wrote:

> Would a more generic
> solution be to modify the sanitize function to just drop invalid
> parameters, log as potential attack, and then do a redirect from php
> with just the valid parameters, or just show the page using the
> validated parameters?
> 

I would perfer to focus our energy on going to flat file format. That
way anyone can send whatever they like because it will be basic html
they get.

-- 
Regards,

Ken Fallon
http://kenfallon.com
http://hackerpublicradio.org/correspondents.php?hostid=30



signature.asc
Description: OpenPGP digital signature
___
Hpr mailing list
Hpr@hackerpublicradio.org
http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org

Re: [Hpr] HPR urls doing weird things

[Roan Horning]

On Thu, Sep 10, 2020 at 7:59 AM Ken Fallon  wrote:

> I applied a rewrite rule as shown here
>
> https://blog.paranoidpenguin.net/2018/12/how-to-remove-facebooks-fbclid-parameter-using-mod_rewrite-on-apache-2-4/
>
> So now facebook links will work.
>
> The biggest issues I see using rewrite rules are their brittleness and
maintainability. If we decide that Facebook is going to be the only site on
the acceptable list and rewrite their parameters out, then this is fine.
Maybe adding one or two others if they seem to be a big source of
legitimate traffic, won't be a problem, but if any of them changes their
parameter name, then the rewrite breaks, and needs to be updated. The
bigger the list the more maintenance.



> >> Wouldn't accepting parameters from others pose a security problem? I
> >> tend to think it expands the attack surface.
>
As Ken points out, we already sanitize the parameters, and treat any extra
as an attack. I assume the above rewrite rule occurs before the php
sanitization code, which now allows it to pass. Would a more generic
solution be to modify the sanitize function to just drop invalid
parameters, log as potential attack, and then do a redirect from php with
just the valid parameters, or just show the page using the validated
parameters?
___
Hpr mailing list
Hpr@hackerpublicradio.org
http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org

Re: [Hpr] HPR urls doing weird things

[x1101]

Excellent. I think this is an excellent, very specific solution.

On 9/10/2020 07:58, Ken Fallon wrote:

I applied a rewrite rule as shown here
https://blog.paranoidpenguin.net/2018/12/how-to-remove-facebooks-fbclid-parameter-using-mod_rewrite-on-apache-2-4/

So now facebook links will work.


Wouldn't accepting parameters from others pose a security problem? I
tend to think it expands the attack surface.

On 2020-09-10 00:10, Cedric De Vroey wrote:

No it doesn't really, as long as you use named parameters, and as long
as you implement proper sanitation on those parameters you should be
fine from a security perspective.

I agree if you mean just adding this one extra parameter.

I disagree if you mean allowing any extra parameters. Checking that the
parameter match our allowable list is part of a good defense in depth
strategy. By triggering this check, we know the person is an attacker,
and can use that information as part of our defense.



However, there are privacy concerns
that could be made over this practice since it could be used to track users.


This looks like an attempt to bypass the EU cookie law.



___
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

Re: [Hpr] HPR urls doing weird things

[Ken Fallon]

I applied a rewrite rule as shown here
https://blog.paranoidpenguin.net/2018/12/how-to-remove-facebooks-fbclid-parameter-using-mod_rewrite-on-apache-2-4/

So now facebook links will work.

>> Wouldn't accepting parameters from others pose a security problem? I
>> tend to think it expands the attack surface.

On 2020-09-10 00:10, Cedric De Vroey wrote:
> No it doesn't really, as long as you use named parameters, and as long
> as you implement proper sanitation on those parameters you should be
> fine from a security perspective.

I agree if you mean just adding this one extra parameter.

I disagree if you mean allowing any extra parameters. Checking that the
parameter match our allowable list is part of a good defense in depth
strategy. By triggering this check, we know the person is an attacker,
and can use that information as part of our defense.


> However, there are privacy concerns
> that could be made over this practice since it could be used to track users.
> 

This looks like an attempt to bypass the EU cookie law.


-- 
Regards,

Ken Fallon
http://kenfallon.com
http://hackerpublicradio.org/correspondents.php?hostid=30



signature.asc
Description: OpenPGP digital signature
___
Hpr mailing list
Hpr@hackerpublicradio.org
http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org

Re: [Hpr] HPR urls doing weird things

[Jon Doe]

By the action coming from facebook, I wonder if one of the systems they are
running it through is simply not properly sanitising that extra string out
of there. "Never attribute to malice what can easily be explained by
stupidity," as it is said.

On Wed, Sep 9, 2020 at 5:11 PM Cedric De Vroey via Hpr <
hpr@hackerpublicradio.org> wrote:

>
> Op wo 9 sep. 2020 om 23:55 schreef Kevin O'Brien :
>
>> Wouldn't accepting parameters from others pose a security problem? I tend
>> to think it expands the attack surface.
>>
>
> No it doesn't really, as long as you use named parameters, and as long as
> you implement proper sanitation on those parameters you should be fine from
> a security perspective. However, there are privacy concerns that could be
> made over this practice since it could be used to track users.
>
>
>
>> Regards,
>>
>>
>> --
>> Kevin B. O'Brien
>> z wil...@zwilnik.com
>> http://google.me/+kevinobrien
>> http://www.google.com/profiles/Ahuka5656
>> http://about.me/zwilnik
>> “People shouldn't be afraid of their government. Governments should be
>> afraid of their people.” - Alan Moore, *V for Vendetta*
>> *Public Key = F6283E7A *
>>
>>
>>
>> On Wed, Sep 9, 2020 at 12:13 PM Ken Fallon  wrote:
>>
>>> On 2020-09-09 18:10, Cedric De Vroey via Hpr wrote:
>>> > 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 :-)
>>>
>>> Actually that's the ones that make it through Joshes bear traps ;-)
>>>
>>> --
>>> Regards,
>>>
>>> Ken Fallon
>>> http://kenfallon.com
>>> http://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
>>
> ___
> 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

Re: [Hpr] HPR urls doing weird things

[Cedric De Vroey via Hpr]

Op wo 9 sep. 2020 om 23:55 schreef Kevin O'Brien :

> Wouldn't accepting parameters from others pose a security problem? I tend
> to think it expands the attack surface.
>

No it doesn't really, as long as you use named parameters, and as long as
you implement proper sanitation on those parameters you should be fine from
a security perspective. However, there are privacy concerns that could be
made over this practice since it could be used to track users.



> Regards,
>
>
> --
> Kevin B. O'Brien
> z wil...@zwilnik.com
> http://google.me/+kevinobrien
> http://www.google.com/profiles/Ahuka5656
> http://about.me/zwilnik
> “People shouldn't be afraid of their government. Governments should be
> afraid of their people.” - Alan Moore, *V for Vendetta*
> *Public Key = F6283E7A *
>
>
>
> On Wed, Sep 9, 2020 at 12:13 PM Ken Fallon  wrote:
>
>> On 2020-09-09 18:10, Cedric De Vroey via Hpr wrote:
>> > 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 :-)
>>
>> Actually that's the ones that make it through Joshes bear traps ;-)
>>
>> --
>> Regards,
>>
>> Ken Fallon
>> http://kenfallon.com
>> http://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
>
___
Hpr mailing list
Hpr@hackerpublicradio.org
http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org

Re: [Hpr] HPR urls doing weird things

[Kevin O'Brien]

Wouldn't accepting parameters from others pose a security problem? I tend
to think it expands the attack surface.

Regards,


-- 
Kevin B. O'Brien
z wil...@zwilnik.com
http://google.me/+kevinobrien
http://www.google.com/profiles/Ahuka5656
http://about.me/zwilnik
“People shouldn't be afraid of their government. Governments should be
afraid of their people.” - Alan Moore, *V for Vendetta*
*Public Key = F6283E7A *



On Wed, Sep 9, 2020 at 12:13 PM Ken Fallon  wrote:

> On 2020-09-09 18:10, Cedric De Vroey via Hpr wrote:
> > 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 :-)
>
> Actually that's the ones that make it through Joshes bear traps ;-)
>
> --
> Regards,
>
> Ken Fallon
> http://kenfallon.com
> http://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

Re: [Hpr] HPR urls doing weird things

[Ken Fallon]

On 2020-09-09 18:10, Cedric De Vroey via Hpr wrote:
> 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 :-)

Actually that's the ones that make it through Joshes bear traps ;-)

-- 
Regards,

Ken Fallon
http://kenfallon.com
http://hackerpublicradio.org/correspondents.php?hostid=30



signature.asc
Description: OpenPGP digital signature
___
Hpr mailing list
Hpr@hackerpublicradio.org
http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org

Re: [Hpr] HPR urls doing weird things

[Cedric De Vroey via Hpr]

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 :

> 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  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
>>
>
> ___
> H

Re: [Hpr] HPR urls doing weird things

[Ken Fallon]

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 Fallon
>> http://kenfallon.com
>> http://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 >> > 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
>>>
>>

Re: [Hpr] HPR urls doing weird things

[x1101]

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 Fallon
http://kenfallon.com
http://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 mailto: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 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
___
Hpr mailing list
Hpr@hackerpublicradio.org
http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org

Re: [Hpr] HPR urls doing weird things

[Ken Fallon]

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 Fallon
http://kenfallon.com
http://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  > 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 list
> Hpr@hackerpublicradio.org
> http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org



signature.asc
Description: OpenPGP digital signature
___
Hpr mailing list
Hpr@hackerpublicradio.org
http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org

Re: [Hpr] HPR urls doing weird things

[Roan Horning]

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  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 list
Hpr@hackerpublicradio.org
http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org

Re: [Hpr] HPR urls doing weird things

[Ken Fallon]

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/



signature.asc
Description: OpenPGP digital signature
___
Hpr mailing list
Hpr@hackerpublicradio.org
http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org