投射威胁取决于how,用户提供的文本已纳入动态的QQ。 因此,如果你试图防止注射,那么在查询数据库时,你需要评估用户投入的每一种方式。

In the example you have posted there are two pieces of user input:

1. input$nrows which is limited to numeric by the input widget
2. input$ID which is free text, and hence has greater risk of SQL injection.

您可以采用以下任何方法调查用户的投入。 总的来说,我选择的办法是宣传,然后审查。

回答的重点是你利用yr子从R-QL转换的情况。 如果使用其他方法进入数据库(例如书目表包),则需要采取不同的做法。

Option 1) Review the SQL query that is generated

考虑在什么地方使用<代码>Input$ID。

pool %>%
  tbl("City") %>%
  filter(ID == !!input$ID)

为了执行这一规定,dbplyr将发射机从R.K.转变为L.。 我们可以使用<代码>show_query/code>的指令来审查这一翻译。

pool %>%
  tbl("City") %>%
  filter(ID == !!input$ID) %>%
  show_query()

This will probably produce an SQL query similar to the following:

SELECT *
FROM city
WHERE ID ==  my_id_value 

你们不需要全方位 用于检测这一卡片的注射。 你们可以简单地改变这种态度,看一看发生什么。 例如,尝试一个简单的替代问题:

attempt_inject =  my_id_value;SELECT 123 
pool %>%
  tbl("City") %>%
  filter(ID == !!attempt_inject) %>%
  show_query()

I suspect this will produce SQL similar to the following:

SELECT *
FROM city
WHERE ID ==  my_id_value;SELECT 123 

这对卡片注入来说似乎是一种有效的预防。 但是,你们需要彻底测试,以确保你们有信心。

Option 2) Review source code

dbplyr包是公开来源,可在网上查阅。 您可以审查源代码,确认在翻译过程中如何处理投入。

我怀疑的是,除非投入类型sql,否则这些投入将作为案文或标语逃脱。

有一个<代码>sql()功能,将输入转换为<代码>sql。 其中一个用途是将电压器不翻译该功能的内容,而是将其用作消耗。 这意味着,如果贵国用户能够将R物体作为投入提交,那么这是一个重大的脆弱性领域。 然而,由于你的评估限制用户提交文字和数字投入,这种情况不太可能发生。

Option 3) Sanitise your inputs before passing them to dbplyr

R与纯粹的QL相比具有若干优势,因为你可以利用R验证用户的投入,然后将这种投入纳入yr门。

考虑这一替代案文,以替代您的<代码>output$tbl。 附录

output$tbl <- renderTable({
  current_ID = as.character(input$ID)
  acceptable_ids = pool %>%
    tbl("City") %>%
    select(ID) %>%
    distinct() %>%
    collect() %>%
    pull()
  req(current_ID %in% acceptable_ids)

  pool %>%
    tbl("City") %>%
    filter(ID == !!current_ID)
})

这种办法规定,用户投入转换为类型,在通过用户投入到灭.器之前,是国际发展法栏中发现的价值。

确切的检查选择将取决于用户投入的使用情况。 我常常包括一项检查,即用户投入不包含特殊特性(例如<代码>;{}[]*或空间)。

dbplyr includes commands to delimit certain inputs. Investigate and use these commands where applicable.

注

• req is a Shiny command that stops execution of a component if the condition is not met. You can use stopifnot outside a Shiny context.
• Fetching the list of acceptable ids within the renderTable statement is not efficient app design. This should be calculated once and reused multiple times.