調査後にカスタム フィードバックを生成するために、openCPU と Knitr を使用しています。この目的のために、私は基本的にサーベイ開発者に rmd ファイルを指定させます。このユース ケースでは、調査の開発者は信頼されていますが、調査の回答者は信頼されていない可能性があります。
私は今XSSについて考えています。もちろん、ユーザーのフィードバックは通常、表示されているデータを入力したユーザーにのみ表示されるため、大きな心配はありませんが、もちろん「<」などの文字は悪意のない理由で使用されます。 R を Web アプリと自由に組み合わせることの試練と苦難のいくつかを調べてください。
Knitr と R は一般的に、信頼できないユーザーと XSS を念頭に置いて作成されたものではありません。OpenCPU は、AppArmored-R を API として実行することで多くのセキュリティ問題を修正しますが、私のような最大の柔軟性アプローチも証明できるかどうか疑問に思います。
信頼できるマークアップと信頼できないマークアップを分ける可能性のあるポイント:
- 編む前に、つまり、エスケープされたユーザーデータを rmd ファイルに渡します。欠点: 意識の低い調査開発者は、誤って、または状況によっては煩わしいため、エスケープしない可能性があります。
- 編み物中。これは理想的だと思いますが、それが可能かどうかはわかりません。特に調査開発者がチャンク設定を変更する可能性がある場合はなおさらです。
- 編んだ後。信頼できるマークアップと信頼できないマークアップを事後的に分離することは不可能だと思います。
OpenCPU の Knitr アプリに貼り付けるコード:
```{r}
good_userdata = 'I like brackets [].'
bad_userdata = 'some text should not be
[linked](javascript:location.href=\'http://example.com?secrets\';), <s>struck</s> or __bold__'
escape_html = highr:::escape_html
escape_md <- function(x){
x <- gsub('\\[', '\\\\[', x);
x <- gsub('_', '\\\\_', x);
x
}
good_userdata_escaped = escape_md(escape_html(good_userdata))
bad_userdata_escaped = escape_md(escape_html(bad_userdata))
```
## let's say survey devs wants to print text like this
```{r}
cat(good_userdata_escaped)
cat(bad_userdata_escaped) # doesn't know about text like this
```
## gets annoyed, does
```{r}
good_userdata_escaped <- gsub('\\\\', '', good_userdata_escaped);
bad_userdata_escaped <- gsub('\\\\', '', bad_userdata_escaped);
```
##
so that this looks nice
```{r}
cat(good_userdata_escaped)
```
## later renders the same text inline, so that is evaluated as markdown
`r good_userdata_escaped # doesn't look dangerous`
`r bad_userdata_escaped`
編集 2
申し訳ありませんが、XSS 攻撃の可能性は明らかだと考えて、いくつかの HTML タグしか提供していませんでした。Michel Fortinのページにいくつかの例がありました。