スイーツ（笑）と呼ばないで!!

そのデータの作成者、簡単に偽装できます!!

と聞いたら誰もがビックリするでしょう。

今日はそんな可能性のあるお話です。

Laravelの初心者向けの講座や書籍でEloquentが紹介されるとき、

class Article extends Model{
　protected $guarded = ['id'];
}

とか書かれたりしますね。

「これはおまじないです」なんて言われて「そうかそうか」と深く考えずにそのまま真似したりします。

で、少し学習が進むと、guardedはブラックリスト、fillableはホワイトリストという感じで理解が進みます。

class Article extends Model{
　protected $fillable= [’title’,’body'];
}

こんな感じでホワイトリストの登録もできる、と。

簡単に表現すると、ブラックリストに書いてある項目はユーザー入力の配列渡しで更新ができない、ホワイトリストに書いてある項目はユーザー入力の配列渡しで更新ができる、ということになります。

そして、ホワイトリストとブラックリストは逆の意味・・・その理解から、「ホワイトリストの登録は面倒だから、テキスト通りブラックリストにidを指定しておけばいいや」と考えたりします。

本当にそうでしょうか？

fillableではなく、guardedを使っている人の多くが、idだけを指定していますね。

確かに、id,title,bodyこれだけしか項目が無ければ同じ意味です。

しかし、実案件ではこれらの他に

created_at
created_by
updated_at
updated_by

こんな項目も裏で用意されていたりしますね。

このようなケースを想定しても、ホワイトリスト方式の場合は、変わらずtitleとbodyしか更新できません。

しかし、ブラックリストでidだけ登録されている場合は、パラメータ偽装で簡単にcreated_byが更新できてしまいます。

実際にChromeの開発者ツールで簡単に試すことができました。

え、その前に頑張って配列を整理しているから問題ない？
そうかも知れません、でもfillableでホワイトリストを設定していれば、そんな努力は不要です。

ブラックリストの設定漏れだと、更新されてはいけないものが更新される可能性があります。
ホワイトリストの設定漏れだと、更新されるべきものが更新されない可能性があります。

さて、どちらのリスクをとるべきでしょうか？

私の好みはホワイトリストの方です。

laravelは私たちにセキュリティを確保するための簡単な仕組みを用意してくれています。
是非その仕組を有効活用して、無駄なコードを減らしましょう。

[0回]

• プログラミング
• COMMENT：0