Re: RFC 9205 vs. CL0P

Eric J Bowman writes:

> We can't even muster a simple, "Don't process raw SQL queries over unauthenticated POST requests"? Really?

I am sympathetic to this suggestion, but probably not for the reason
you hope or expect.

I'm pretty sure it would take me only a few minutes to find several
places where that message is already communicated.

And the WG consensus is undoubtedly that it has been clearly
communicated over and over - and that there is simply no helping
some people.

But as a non-native english reader, I disagree with "clearly".

I had my first english lesson 45 years ago, I have lived in UK and
USA, I was married to a woman from USA, I've been involved in
all-english-speaking FOSS projects like FreeBSD for 30+ years and
yet I still find myself wondering "What precisely are they trying
to tell me here?"

The word-smiths who admirably do the grunt work of turning ideas
into RFC text have usually spoken english from before they were
potty-trained, while watching men on the moon.

Next they spent 15+ years in native english language educational
institutions of increasing sophistication, most of which they were
systematically taught the english language five days a week.

A lot of the people who read the RFCs we turn out have had less
than 5 years formal english education of varying quality, typically
no more than one or two hours a week, outside which they spoke and
read little or no english - until they went into IT.

So while far from semantically identical, more readers would understand:

	Don't process SQL queries over unauthenticated POST requests


	Origin servers often use parameters within the URI as a means of
	identifying system services, selecting database entries, or choosing
	a data source.  However, data received in a request cannot be
	trusted.  An attacker could construct any of the request data
	elements (method, request-target, header fields, or body) to contain
	data that might be misinterpreted as a command, code, or query when
	passed through a command invocation, language interpreter, or
	database interface.
	For example, SQL injection is a common attack wherein additional
	query language is inserted within some part of the request-target or
	header fields (e.g., Host, Referer, etc.).  If the received data is
	used directly within a SELECT statement, the query language might be
	interpreted as a database command instead of a simple string value.
	This type of implementation vulnerability is extremely common, in
	spite of being easy to prevent.

Only Hemmingway is expected to write like Hemmingway, but we should try.


Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Saturday, 19 August 2023 08:20:02 UTC