bug: Fix formatTime escaping
#1727
Conversation
Currently formatTime do not properly escape the timezone info passed to it. Meaning timezone info can contain mallicious SQL. This PR makes sure it's properlty escaped Signed-off-by: Kaviraj <[email protected]>
bind.go
Outdated
| } | ||
|
|
||
| // Escape the timezone string (timezone may contain malicious SQL query) | ||
| escapedTimezone := stringQuoteReplacer.Replace(value.Location().String()) |
There was a problem hiding this comment.
It may be fixes bug but causes sending invalid timezone to server.
We could fix it with https://pkg.go.dev/time#LoadLocation but it might have horrible performance. :-(
There was a problem hiding this comment.
We should not accept invalid timezone and inform application owner about malicious attempt.
the most simple way is to compare length of escaped and unescapted TZ and return error say that TZ contains invalid string and print escaped string.
There was a problem hiding this comment.
Good catch. Not only time.LoadLocation is slow, there also a chance, the timezone location we look up for may not present in the local node that is running (that not necessarily meaning it's invalid).
I think comparing the length approach is decent one. But I'm bit worried it's not full fool proof. Technically there is no limit on the timezone string.
Let me think about it.
There was a problem hiding this comment.
@kavirajk the idea is not to limit string but check if we escaped something.
if UTC or ANY_LONG_TIMEZONE/ON_SOME_FAR_FAR_PLANET is in - then we have nothing to escape and
len(original) == len(escaped).
The main thing here is to catch invalid thing on client side. Most cases it should be fine - but weird names will be blocked and users will create issue if they believe it is a valid timezone.
There was a problem hiding this comment.
Make sense. I added the length check and updated the tests accordingly. @chernser
Add client-side check on invalid timezone name Signed-off-by: Kaviraj <[email protected]>
Summary
Currently formatTime do not properly escape the timezone info passed to it. Meaning timezone info can contain malicious SQL.
This PR makes sure it's properly escaped
Fixes: #1713
Checklist
Delete items not relevant to your PR: