[v14] Security Reports#33459
Conversation
c379f49 to
ff06afa
Compare
ff06afa to
f9233d9
Compare
f9233d9 to
9f11cf6
Compare
|
@smallinsky - this PR will require admin approval to merge due to its size. Consider breaking it up into a series smaller changes. |
zmb3
left a comment
There was a problem hiding this comment.
Boilerplate or not, 11,000 lines is too much for a single PR. A lot of minor things probably would have been caught had this been broken up into a series of smaller changes.
I'm most concerned about the use of Sprintf to build SQL queries. Are we confident we are not susceptible to SQL injection here?
| return "", trace.Wrap(err) | ||
| } | ||
| sb.WriteString(line) | ||
| sb.WriteString("SELECT\n") |
There was a problem hiding this comment.
Roman asked for a comment on the original PR explaining why it is safe to build SQL queries in this manner, but it looks like that was never done.
I'd like to see it too. This type of code is prone to introducing SQL injection vulnerabilities.
There was a problem hiding this comment.
I have added comment but in the e repo where CreateView function is used and forgot to update this one.
Namely access monitoring user can run any Athena SQL Query so protection agains SQL injection doesn't make sense because we are giving a user to run a customer queries.
However Access Monitoring is using a separate IAM role that allows only for read only access to Athena events table: https://github.com/gravitational/cloud/pull/6158/files#diff-0a61b4dbc943463cdee2c13f1dec76ce507b262f2a49473d96470c3d8dfd3ea4R309
Yea, Agree I'm not proud of form of this PR and should split this into smaller chunks in the first place. Lesson learn.
Access monitoring gives a user ability to run a customer SQL query agains Athena audit events table. If a user can run custom SQL query he has full control what is executed. In the result a user query scope is limited only to Athena audit table with read only access. |
93bac2e to
9b18199
Compare
Backprot #30853 to v14