- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Sat, 19 Aug 2023 08:19:49 +0000
- To: Eric J Bowman <mellowmutt@zoho.com>
- cc: "Ietf Http Wg" <ietf-http-wg@w3.org>
-------- 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 than: 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 -- 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