【PHP】Laravel【フレームワーク】 Part.3
■ このスレッドは過去ログ倉庫に格納されています
テンプレ追加修正お願いします
Laravel
ウェブ職人のためのPHPフレームワーク
本家
https://laravel.com/
git
https://github.com/laravel
動画チュートリアル(英語)
https://laracasts.com/
日本語
http://laravel.jp/
書籍
Laravel リファレンス[Ver.5.1 LTS 対応] Web職人好みの新世代PHPフレームワーク
Laravelエキスパート養成読本[モダンな開発を実現するPHPフレームワーク！] (Software Design plus)
※前スレ
【PHP】Laravel【フレームワーク】
https://medaka.5ch.net/test/read.cgi/php/1503683914/
【PHP】Laravel【フレームワーク】 Part.2
https://medaka.5ch.net/test/read.cgi/php/1556417229/
amazonへのリンクが邪魔をしてスレッドを建てられなかったので外しました。 >>287
その前に君の「〇〇っていうフォーマットを使えばパースは安全」
という認識を改めたほうが良いよ >>284
言い過ぎだろ。json仕様に脆弱性はないし（今のとこ）、json_decodeにも脆弱性は見つかってない。
その点でcsvだろうとxmlだろうと、x-www-form-urlencodedだって同じ。（は言い過ぎか） >>288
こどおじには理解できないみたいだからそうせめてやるなよｗ json_decode脆弱性見付かって何回かアップデートかかってるぞ >>289
げ、まる被り（笑）まあ、あとは実装するやつの心がけ次第ということだ。 そうそう。リスク判定できない人はjsonでデータを受け取るなと。 >>291
2009年の脆弱性言われてもなあ。
>>291 json自体の脆弱性の話はしてないんだ。
使い方が悪ければ脆弱性につながりやすいというのを理解できないおこちゃまをどうしてやろうかという話なんだ。 >>295
いや思いっきりJSON固有の話してたのに、急に一般論にして話そらすのやめよう？
話の始まりは >>265 だからそれを見返してね。
「ユーザー入力をJSONでフォーマットするのは危ないですよ」
と
「どんなフォーマットを使ってもユーザー入力は気をつけましょう」
じゃ全然話が違うでしょ >>296
どんなフォーマットだろうが不特定からの入力は、危険だからValidationは必須だよ。
特にjsonとかのデコードを前提とする入力は、さらに慎重なValidationを検討する必要があるよ。
という話をずっとしてるでしょ。 >>297
それなら早く具体的な問題点とJSONに代わるセキュアなフォーマットを挙げてみてよ。
以前のレスにもそう書かれてのになんで挙げないのかな？ 顔真っ赤だな。
jsonはJavascriptとの親和性、csvはExcelとの親和性、XMLは構造の自己記述性とか、それぞれ特徴あって、好きなの選べはいいじゃん。
今回の話はJSONが良さそうに思えるけど、他の選択肢、どんなのあるん？ >>298
たとえばusersテーブルに住所・電話番号を更新させるAPIをつくるとして、
1.住所・電話番号をそれぞれ2つのパラメータとして入力させる場合
住所・電話番号のチェックを行い、それから保存。
2.住所・電話番号を連想配列に格納したものを、json_encodeしたもので入力させる場合（パラメータ1つの場合）
decodeして1と同様のチェックを行う。更に追加でdecode後に要素の過不足が無いかもチェック。それから保存。
という感じで明らかにチェックしなければならないことが増えてしまう。
そして万が一追加チェックを忘れてしまうと、実装によっては脆弱性になりかねない。 >>296
>>265はいまどきJSONでやり取りしているの？って言っただけであって
セキュリティのことは言ってなくないか？ >>298
お前が挙げろよｗ
論破されたからってなりすましは良くないと思います >>300
頓珍漢すぎるでしょ、
content-type ヘッダを application/x-www-form-urlencode で指定して、
その中身は実はjsonだったって場合の話してるの？
そんな実装ありえたにし、そもそもバリデーションを通さないでしょ。
jsonの場合なんだから、content-type は application/json で送って処理させるでしょ。
なんで、jsonって言ってるのに x-www-form-urlencode で送るのｗｗ？ >>300
curlで書くとこういうの想定してる？
curl "http://example.com"; \
-X POST \
-d "key={\"key\": \"param\"}" \
-H "Content-Type: application/x-www-form-urlencoded"
ありえないでしょ…
普通こうだよ。
curl "http://example.com"; \
-X POST \
-d "{\"key\": \"param\"}" \
-H "Content-Type: application/json"
そもそもミドルウェアレベルで弾く話だと思うんだけど、変な例ださないでよ。 >>300
うわーそうきたか
確かにそれは誰も想定できないね
JSON危険厨はやっぱレベルが違う 300の書きたかったことが304のようなことだったとして、結局inputに余計な要素が含まれていないかのチェックは実装によっては必須になるな。 >>307
それいったらJSON関係ないね。
application/json ではそれが必要なのに
application/x-www-form-urlencode にしたら不要になるって話じゃないでしょ。
ちなみに、Laravelの場合は fillable か guarded 設定しないと、
(new User)->fill($request->all())
みたいなことはフレームワークレベルで出来ないから、そっちもあんま関係ないね。 お前らJSONの脆弱性についてまったく理解してないんだな
さっきから的外れなこと言いすぎ
なんだろう俺とお前らの技術レベルの差がありすぎてまともな
議論にならないな >>309
アプリ設計者の想定外のデータが復元されうること以外になんかあったっけ？ だから送信は普通にPOSTするって言ってるだろ
JSON使うのはサーバー→クライアントだけだって >>311
まず EloquentModel の fill メソッドは分かるよな？
もし分からなければ、それについてマニュアル読んでからきてくれ。
例えば >>300 のケースでシミュレータする
usersテーブルにinsertする為のUIがあったとして、
その入力結果をサーバーに送信する際、どんなフォーマットが適切（よりセキュア）なのかが今回の焦点。
>>300 が言っているのは
「パラメータ部分を
-d "user={"address": "東京", "tel": "08012345678"}"
にすると、request()->get('user') をjson_decodeした上で、userの中に余計な属性が無いことを担保しなくてはならない」
と言っている。
（クォーテーションのエスケープは省略するから脳内補完して欲しい）
で、担保する必要があるのは大体、Userモデルに対し fill($request->all()) するようなケース。
（今回だと $casts = ['user' => 'json'] で定義された fill(request()->get('user')) かもしれない。 ）
担保するって言っても $fillable を定義すれば良いだけだが。
そんなフォーマットはありえないから置いておくとして、
実際によくあるのは下の2パターン。
-d "address=東京&tel=08012345678" -H "Content-Type: application/x-www-form-urlencoded"、
-d "{"address": "東京", "tel": "08012345678"}" -H "Content-Type: application/json"
で、余計な属性が無いか担保する場合は前者も後者も変わらない。
逆に、前者の場合は担保が必要なくなる言ってるのはそれはそれで問題だね。
書き方はLaravelで例えたけど言語やフレームワーク変えても書き方が変わるだけで考え方は同じ。 >>312
だからお前が言う普通のPOSTって何だよ
curlで書いてみてくれ なんでcurlなんだよ
URLSearchParamsとかFormDataにappendしたパラメーターをaxiosに渡すような極々シンプルなPOSTだよ なんでcurlでかくのをそこまで拒むの？
本当は俺らの議論についていけてないだけじゃないのか？ >>312
httpメソッドが何かなんて誰も焦点にあててないのに何で急にPOSTが出てきた？ json_encodeやらjson_decodeって関数名が出てくるのがまずおかしい >>315
いや、curlじゃなくても良いんだけどね。
言語に依存しない点で例に適切だろうからcurlが良いなって思っただけだよ。
で、その場合はaxiosにjavascriptオブジェクトを渡してapplication/jsonをPOSTするのと比べてどう適切（セキュア）なの？ ここまでの流れ
JSONは危険おじさん 「JSONは危険」
何が危険なのおじさん「何が危険なの」
JSONは危険おじさん 「パースする時が危険」
何が危険なのおじさん「何が危険なの」
JSONは危険おじさん 「危険なものは危険」
何が危険なのおじさん「危険な例をだせよ」
JSONは危険おじさん 「普通にPOSTするだけ」 >>320
普通にPOSTするだけ は 何が危険なのおじさん の方だよ >>321
普通にPOSTするだけおじさんは「サーバー→クライアントにしかjsonを使わない」って言ってるよ
例もjsonじゃなかったし でも実際JSONは危険だよね
去年のやつだってJSONの解析処理を逆手にとって
顧客情報盗まれたわけだし そういえばLaravelの次期バージョンでフレームワークによるJSONサポートをなくそうかって話出てるね
多分この案は採用されないだろうけどさ >>325
とりあえずissue見てみたけど見つからん
どこに書いてあるの？ 結局「JSONは危険おじさん」による具体例と代替フォーマット無し ヘッダーとしてAuthorization: Bearerで認証トークンくっつけて送信しろボケナスくんたち >>324
去年の奴ってなんだよw
去年あった大きい事件で言えばセブンペイのパスワードリセットの件か？
JSONは関係無かったが 今はContent-typeにapplication/jsonを指定することの是非を話していて、
Authorizationヘッダは関係無いよ。
それともお前の頭の中ではAuthorizationヘッダにBearerトークンを指定するとなぜか急にJSONのパースがセキュアになんのかよｗ 一つの仕組みだけでセキュアな送受信なんかできねーのに一つの仕組みだけにこだわってるボケナスくん curlの話してたら結局API認証の話になるのはある意味仕方ない >>333
うん、じゃあAuthorizationヘッダにBearerトークンを指定するとJSONのパースがセキュアになる理由もどうぞ。 スレの流れ見る限りJSONは危険じゃないよおじさんの負けでいいんじゃないかな？
何ら反論できていないし JSON危険おじ「JSON送信するのは危険」
何が危険おじ「何が危険なの」
JSON危険おじ「パースするとき危険」
何が危険おじ「どう危険なの」
JSON危険おじ「危険なものは危険」
何が危険おじ「危険な具体例と危険じゃないフォーマットは？」
JSON危険おじ「普通にPOSTすればいい」
何が危険おじ「普通って何？content-typeで言うと？」
JSON危険おじ「…」
何が危険おじ「もしかしてx-www-form-urlencode？同じじゃん」突然現れた謎のおじ「Bearerトークン付ければ安全」
何が危険おじ「BearerトークンとJSONのパースは関係無いけど？」
で危険な具体例まだー？
結局 >>300 だけなの？彼は論破されたままダンマリだけど。 >>338
いいんじゃない？JSON嫌いおじさんは妄想で生きてけるんだし。
何も実例出さない段階でお察しだから。
CSVをJSONにしたら脆弱性出て、XMLにしたら直って、YAMLだとパフォーマンスが出なくて、x-www-form-urlencodedだとセキュアじゃない、はいはい、それ全部実装とバリデーションの問題だから。 だからお前が言う普通のPOSTって何だよ
curlで書いてみてくれ >>344
コピペじゃねーよ
俺がずっとcurlで例を書いてくれって言ってるのに結局書いてくれないから催促している マジレスするとjsonが一番脆弱性が多いというのは確か
jsonの解析処理に問題があるからしょうがないね >>347
jsonそのものじゃなくjson起因な >>346
その話って >>319 で片付いてるじゃん。
なんでわざわざ騙るんだろう？
x-www-form-urlencode は json と比べてどうセキュアですか？という質問に回答できなくて（論破されて）悔しかったのか。 >>341
これだけでいい。
危険おじ「jsonは危険」
疑問おじ「どう危険なの？」
危険おじ「…」
危険おじ「jsonは危険」
疑問おじ「日本語わかる？」 >>351
素人にはわからないかもしれないが、サーバ側で不特定の相手からjson形式でデータを受けるときは、セキュリティ上考慮すべきことが増えるんだよ。 まあLaravelでjson使おうとするやつはlaravelについて勉強しなおしたほうがいいと思う
これがsymfonyでjsonだったらわかるんだけど >>354
まさか今どきJSONくんもだけどどうして理由を添えて書けないかなぁ >>354
マジ？
俺はどこから勉強しなおしたほうがいいですか？
教えてください師匠 >>356
脆弱性とは何か、セキュリティの基本から でもLaravelってsymfonyのラッパーみたいなもんだよね
内部的にはsymfony関連クラスのサブクラスみたいな感じで
作られているわけだし >>357
でも「Laravelについて」、って言ってましたよね？
え、ってことはLaravelの脆弱性って今何か報告されてるんですか？
セキュリティサポートが続いている 7.x、6.x、5.5.x で何かありましたっけ？
issue探してみたんですが、JSON関連は特にありませんでした！ >>359
そいつもはや荒らしだから触らないほうがいいぞ 確かにLaravelでjsonを扱うのは結構難しいよね 考慮することが多い気がする
その点symfonyだと考慮するべきことのほとんどがフレームワーク側でチェックが入るので安心して使える
ただ細かい制御をしたいんだったらLaravel一択 フロントエンドからのリクエストに対してJson形式でレスポンスで返すバックエンドを仕事で構築したことがあるけど
laravel制アプリは脆弱性のテストツールで唯一jsonハイジャック対策が不合格になったのに対してsymfony制アプリはすべて合格だった
まあlaravel制アプリも結局設定変更レベルで合格になったけどsymfonyは確かにデフォルト設定のセキュリティレベルがlaravelより高いような感じ >>363
> Json形式でレスポンスで返すバックエンド
あれ、結局サーバー→クライアントの通信の話なの？
ユーザー入力をサーバーサイドでパースするのが問題だっていう設定どこに消えたのw >>363
> jsonハイジャック
急にクライアントの話になってて草
それとも>>363が作ったアプリではphpからjavascriptを動かしていたのだろうか >>363
laravelとsymfonyで全く同じアプリ作ったの？
同じアプリ作る意味が分からんけど、フレームワークが異なれば実装も異なるんじゃないの？
実装が異なるのにフレームワークの責務と言い切れるの？
すっごくシンプルなアプリならともかく、php製のjavascriptクライアント作っちゃうくらいだからやっぱりフレームワーク関係ないのでは？
しかもツールによる診断項目ってポートスキャンとかに限られてるだろうし、せいぜいインフラ構成くらいしか診断できないでしょ。 JSON危険おじさん、嘘を見破られてまたまた論破されてしまう。 >>364
すまん俺はその人ではない
>>365
phpのv8js使って色々やってます
>>366
自分の所は毎回laravelとsymfonyの２種類で同じアプリを作成し、その時点で
一番脆弱性が少ないフレームワークを本番環境にリリースする形です
まあ会社の方針ではなく顧客の入札仕様に入っているのでしょうがないんです（；ω；）
チェックツールについてはポートスキャンだけじゃなく画面で自動入力したり不正なリクエスト送ったりする
テストツールがあるんでそれ使ってました富士通製とNTTデータ製の２ツールで毎回テストやってます v8jsってなんだよｗｗｗって思ったらマジであるのかｗ ここまでの結論としてはjsonに脆弱性はないけどcsvにはあるということでＯＫ？ 正直jsonよりもxmlのほうが扱いやすいと思ってるの俺だけ？ >>372
脆弱性を一番産みやすいのは人間だから、
だめな人間はプログラムするなという結論だな。 ブラウザアプリに限った話だけど、
SPA作る場合って、特殊な事情を除けばサーバーへのリクエストはほぼ Content-Type: application/json 一択になる。
SPAの時点でクライアントがjavascript一択なのでjsonが一番ラクというのは非職業エンジニア（少しだけコードを書く素人）でも分かるだろう。
それで、一昔前の非SPAでよくあったHTMLフォームから直接サーバーへのPOSTリクエストを行う場合、Content-Type は自動的に application/x-www-form-urlencode または multipart/form-data になる。自動的に設定されるのでそれ以外の選択肢は無いし、そもそも Content-type を意識することすら無いだろう。
（代表的なアプリでいうとWordPressだろうか）
もしかしてJSON危険説を提唱する彼（ら）は非SPAを作ることだけを想定して「jsonはありえない」と否定していたのだろうか。
しかしそうすると「まさかいまどきJSONでやり取りしてるの？」というレスにひっかかる。
どちらかと言えば非SPAアプリのほうが前時代的なので「いまどき」という枕詞が付くのはむしろ x-www-form-urlencode のほうではないだろうか。 いつからcontents typeの話が出てきたんだ？クライアント→サーバでjsonがどうこうの話じゃないんだっけ？ >>379
「クライアント→サーバーでjsonがどうこう」ってのが曖昧な表現で、正確に書くとcontent-typeを何を指定する？って話になるよ。 要約してやるよ
jsonおじさんは名前がジェイソンだから危険って言ってるんだよ ずっと静観してたけど、ひとつだけ。
俺はおっさんじゃなくおばさんだよ。失礼な！ >>381
13日の金曜日は危険だからジェイソンに気を付けろって話だろ 外注選定でここ数年Laravelばかりやってる奴はまずNGにする。
Laravelでしか物を作れないから。 Laravelでしか物を作れないってどういうこと？ >>384
throttleエラーも直せなかったおじさんまだ生きてたの？
>>56と>>58への返信早く書いてよ。 ■ このスレッドは過去ログ倉庫に格納されています
