Laatste stand van zaken omtrent appsecurity.nl

[Romy Drenth]

Geachte heer/mevrouw,

Vandaag start de verkoop van de domeinnaam appsecurity.nl.
Heeft U interesse?

Met vriendelijke groet,

Romy Drenth

Re: [PATCH] MEDIUM: sample: Modify fetchers for req.hdrs and res.hdrs to selectively include / exclude headers

[Ruei-Bang Chen]

Hi Willy,

Thank you for the response. This is a very interesting topic. Different 
approaches do have their own pros and cons and no matter which way we decide to 
use, we have to make sure it can be extended easily.

I'll think more about this and have some more discussions within the team 
before getting back to you.

Thanks,
Ruei-Bang

From: Willy Tarreau 
Sent: Friday, January 19, 2024 6:28 AM
To: Ruei-Bang Chen 
Cc: haproxy@formilux.org 
Subject: Re: [PATCH] MEDIUM: sample: Modify fetchers for req.hdrs and res.hdrs 
to selectively include / exclude headers

Hi Ruei-Bang,

On Tue, Jan 09, 2024 at 07:18:14PM +, Ruei-Bang Chen wrote:
> Hi Willy,
>
> Hope you are doing well in the New Year!

Yep, thank you!

> I just want to bump this thread so that we can continue the discussion.
>
> I understand you probably have a lot of emails to catch up on recently so
> there is no urgency for this. Just want to make sure this thread does not get
> lost.

I've looked everywhere, both in my own mbox and the list archive and
couldn't find any trace of it, so I suspect that it possibly remained
only in your outbox, or was victim of a hiccup on the send side, so
thanks for resending!

Some comments below.

> 
> From: Ruei-Bang Chen 
> Sent: Tuesday, December 12, 2023 5:32 PM
> To: Willy Tarreau 
> Cc: haproxy@formilux.org 
> Subject: Re: [PATCH] MEDIUM: sample: Modify fetchers for req.hdrs and 
> res.hdrs to selectively include / exclude headers
>
> Hi Willy,
>
> Sorry for the late reply. I know it has been some time since our last 
> discussion.
> I finally have a chance to follow up on this  after working on some other 
> tasks
> and the Thanksgiving break.
>
> What I'm suspecting is that if
> users find it useful, it will not be long before some ask for a way to
> designate prefixes (e.g. select x-companyname-*, or exclude accept-* etc).
> The way you did it will make it easy to extend it for this, for example,
> by appending '*' to a header name, so that's fine. Hmmm well, '*' is
> actually permitted in header field names, so maybe another solution could
> be that we consider that we'd use prefixes by default and terminante names
> with ':' to designate full names. E.g. req.hdrs(accept:) would match only
> "accept" while req.hdrs(accept) would also match accept-encoding,
> accept-range etc. It's just up to us to decide (and you first since you're
> the first one to need this, so the ability to extend this and/or to factor
> arguments may be relevant to your use case.
> Yeah, I think that would be a possible ask / need from the client.
> Currently, we don't have the immediate need for this but I agree at some point
> this feature might come in handy even for us as well. I am thinking maybe
> it can be left as a separate follow-up patch after this one? Let me know if 
> you
> feel strongly that we should include this in the current patch.

Yes, I'm perfectly fine with a later follow-up. I mentioned this to make
sure that we think about it early, in case it requires to refine the syntax
*before* we corner ourselves at the wrong place, because once it's part
of a released version, you cannot change it in a breaking way anymore.
For example if we decide that an argument currently is an exact match,
it cannot later become a prefix. We still have some choice of other chars
to denote prefixes if needed, as listed in RFC9110 section 5.6.2 (header
field names are tokens):

  Tokens are short textual identifiers that do not include whitespace or
  delimiters.

  token  = 1*tchar
  tchar  = "!" / "#" / "$" / "%" / "&" / "'" / "*"
 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
 / DIGIT / ALPHA
 ; any VCHAR, except delimiters

  Many HTTP field values are defined using common syntax components, separated
  by whitespace or specific delimiting characters. Delimiters are chosen from
  the set of US-ASCII visual characters not allowed in a token (DQUOTE and
  "(),/:;<=>?@[\]{}").

Parenthesis and comma are already used to delimit the names in the
expression, but others like "@", "?" or "/" would not cause problems
if needed.

> Similarly I'm seeing that having the '!' in the first argument does add
> some special cases everywhere down the inner loop. Maybe just having a
> new name such as "req.hdrs_exc()" to enumerate exclusion would simplify
> everything, and possibly make it easier even for APIs which will feed
> these arguments, so as to remove the special case of the first argument.
> I don't know, but feel free to explore such possibilities, it's important
> to think about how configs will be used and updated. Very often the amount
> of work needed to make the core easy to use is less than the work needed
> externally to adapt to it ;-)
> This makes sense. After discussing within the team, we think it might be 
> easier
> to just add separate new fetchers like "req.hdrs_inc", "req.hdrs_exc", 
> 

HAProxy Technologies NERC CIP 13 Vendor Questionnaire

[Robert Dillabough]

Hi Support,

For NERC compliance, CORE needs to perform a CIP-013 Cyber Security Supply 
Chain Risk Assessment on HAProxy Technologies. Attached is CIP-013 
Questionnaire. If you could fill it out to the best of your ability and return 
it to me that would be much appreciated. Once returned, the Compliance Team 
here at CORE will review your answers. CIP-013's purpose is to mitigate cyber 
security risks to the reliable operation of the Bulk Electric System (BES) by 
implementing security controls for supply chain risk management of BES Cyber 
Systems. If I need to email this to another person or group, can you please 
direct me to them. If you have any questions, please feel free to contact me, 
all my information is in my signature below.
Thanks,
Robbie Dillabough
Electrical Engineer - Operations

800.332.9540 DIRECT
720.733.5672 MAIN
303.880.9912 MOBILE
rdillabo...@core.coop

[cid:image001.png@01DA4D43.4819F820]

[cid:image002.png@01DA4D43.4819F820]
[cid:image003.png@01DA4D43.4819F820]
[cid:image004.png@01DA4D43.4819F820]
[cid:image005.png@01DA4D43.4819F820]
[cid:image006.png@01DA4D43.4819F820]












CIP-013-2 Vendor Questionnaire v1.0.docx
Description: CIP-013-2 Vendor Questionnaire v1.0.docx

show stat (CSV format) seems broken .

[Emeric Brun]

Hi All,


Enabling agent-check brokes the parsing of the show stat's CSV for multiple 
script/soft parser I use:


3934 recvfrom(7, "L7OK,200,0,0,0,0,0,0,00,0,0,-1,,\"agent warns : 
Backend is using a static LB algorithm and only accepts weights '0%' and ", 
128, 0, NULL, NULL) = 128
3935 recvfrom(7, "'100%'.\n\",0,0,0,0,CHECKED,,4,Layer7 check passed,No status 
change,2,3,4,1,1,1,172.16.27.21:80,,http0,0,0,,,0,,0,0,0,0,0,", 128, 0, 
NULL, NULL) = 128


On the second line you see an unescaped '\n' between quotes is returned. But 
most of CSV parser are using line by line parsing and it is now broken.

I'm not sure such unescaped \n is authorized in a CSV even if between quotes. 

This issue was firstly showed on v2.8 but not sure it affects previous versions.

Emeric