>>299
たとえばusersテーブルに住所・電話番号を更新させるAPIをつくるとして、

1.住所・電話番号をそれぞれ2つのパラメータとして入力させる場合
住所・電話番号のチェックを行い、それから保存。
2.住所・電話番号を連想配列に格納したものを、json_encodeしたもので入力させる場合（パラメータ1つの場合）
decodeして1と同様のチェックを行う。更に追加でdecode後に要素の過不足が無いかもチェック。それから保存。

という感じで明らかにチェックしなければならないことが増えてしまう。
そして万が一追加チェックを忘れてしまうと、実装によっては脆弱性になりかねない。

>>297
>>266はいまどきJSONでやり取りしているの？って言っただけであって
セキュリティのことは言ってなくないか？

>>299
お前が挙げろよｗ
論破されたからってなりすましは良くないと思います

>>301
頓珍漢すぎるでしょ、
content-type ヘッダを application/x-www-form-urlencode で指定して、
その中身は実はjsonだったって場合の話してるの？
そんな実装ありえたにし、そもそもバリデーションを通さないでしょ。

jsonの場合なんだから、content-type は application/json で送って処理させるでしょ。
なんで、jsonって言ってるのに x-www-form-urlencode で送るのｗｗ？

>>301
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"

そもそもミドルウェアレベルで弾く話だと思うんだけど、変な例ださないでよ。

>>301
うわーそうきたか
確かにそれは誰も想定できないね
JSON危険厨はやっぱレベルが違う

>>305
問題はそこじゃないと。。。

300の書きたかったことが304のようなことだったとして、結局inputに余計な要素が含まれていないかのチェックは実装によっては必須になるな。

>>308
それいったらJSON関係ないね。
application/json ではそれが必要なのに
application/x-www-form-urlencode にしたら不要になるって話じゃないでしょ。

ちなみに、Laravelの場合は fillable か guarded 設定しないと、
(new User)->fill($request->all())
みたいなことはフレームワークレベルで出来ないから、そっちもあんま関係ないね。

お前らJSONの脆弱性についてまったく理解してないんだな
さっきから的外れなこと言いすぎ
なんだろう俺とお前らの技術レベルの差がありすぎてまともな
議論にならないな

>>310
アプリ設計者の想定外のデータが復元されうること以外になんかあったっけ？

>>309
すまんどういうことだ？解説してくれ

だから送信は普通にPOSTするって言ってるだろ
JSON使うのはサーバー→クライアントだけだって

>>313
だからお前が言う普通のPOSTって何だよ
curlで書いてみてくれ

なんでcurlでかくのをそこまで拒むの？
本当は俺らの議論についていけてないだけじゃないのか？

>>313
httpメソッドが何かなんて誰も焦点にあててないのに何で急にPOSTが出てきた？

json_encodeやらjson_decodeって関数名が出てくるのがまずおかしい

ここまでの流れ
JSONは危険おじさん　「JSONは危険」
何が危険なのおじさん「何が危険なの」
JSONは危険おじさん　「パースする時が危険」
何が危険なのおじさん「何が危険なの」
JSONは危険おじさん　「危険なものは危険」
何が危険なのおじさん「危険な例をだせよ」
JSONは危険おじさん　「普通にPOSTするだけ」

>>321
普通にPOSTするだけ　は　何が危険なのおじさん　の方だよ

>>322
普通にPOSTするだけおじさんは「サーバー→クライアントにしかjsonを使わない」って言ってるよ
例もjsonじゃなかったし

>>273

でも実際JSONは危険だよね
去年のやつだってJSONの解析処理を逆手にとって
顧客情報盗まれたわけだし

そういえばLaravelの次期バージョンでフレームワークによるJSONサポートをなくそうかって話出てるね
多分この案は採用されないだろうけどさ

>>326
とりあえずissue見てみたけど見つからん
どこに書いてあるの？

結局「JSONは危険おじさん」による具体例と代替フォーマット無し

ヘッダーとしてAuthorization: Bearerで認証トークンくっつけて送信しろボケナスくんたち

>>325
去年の奴ってなんだよw
去年あった大きい事件で言えばセブンペイのパスワードリセットの件か？
JSONは関係無かったが

微妙に違うおじさんが5人くらいいる気がする

今はContent-typeにapplication/jsonを指定することの是非を話していて、
Authorizationヘッダは関係無いよ。
それともお前の頭の中ではAuthorizationヘッダにBearerトークンを指定するとなぜか急にJSONのパースがセキュアになんのかよｗ

おじさんそれぞれ名前を付けてくれや

一つの仕組みだけでセキュアな送受信なんかできねーのに一つの仕組みだけにこだわってるボケナスくん

curlの話してたら結局API認証の話になるのはある意味仕方ない

>>332
なるだろ　無知を晒すなよｗ

>>334
うん、じゃあAuthorizationヘッダにBearerトークンを指定するとJSONのパースがセキュアになる理由もどうぞ。

>>336
>>337

スレの流れ見る限りJSONは危険じゃないよおじさんの負けでいいんじゃないかな？
何ら反論できていないし

>>337
自演たのしいでちゅか？（＾＾；）

ボケナスjsonパースジジイは一生ビビってろ

JSON危険おじ「JSON送信するのは危険」
何が危険おじ「何が危険なの」
JSON危険おじ「パースするとき危険」
何が危険おじ「どう危険なの」
JSON危険おじ「危険なものは危険」
何が危険おじ「危険な具体例と危険じゃないフォーマットは？」
JSON危険おじ「普通にPOSTすればいい」
何が危険おじ「普通って何？content-typeで言うと？」
JSON危険おじ「…」
何が危険おじ「もしかしてx-www-form-urlencode？同じじゃん」突然現れた謎のおじ「Bearerトークン付ければ安全」
何が危険おじ「BearerトークンとJSONのパースは関係無いけど？」

で危険な具体例まだー？
結局 >>301 だけなの？彼は論破されたままダンマリだけど。

>>339
いいんじゃない？JSON嫌いおじさんは妄想で生きてけるんだし。
何も実例出さない段階でお察しだから。
CSVをJSONにしたら脆弱性出て、XMLにしたら直って、YAMLだとパフォーマンスが出なくて、x-www-form-urlencodedだとセキュアじゃない、はいはい、それ全部実装とバリデーションの問題だから。

だからお前が言う普通のPOSTって何だよ
curlで書いてみてくれ

出たなコピペマン

laravelより日本語勉強しなよオッサンたち

>>345
コピペじゃねーよ
俺がずっとcurlで例を書いてくれって言ってるのに結局書いてくれないから催促している

マジレスするとjsonが一番脆弱性が多いというのは確か
jsonの解析処理に問題があるからしょうがないね

>>348
jsonそのものじゃなくjson起因な

>>347
その話って >>320 で片付いてるじゃん。
なんでわざわざ騙るんだろう？
x-www-form-urlencode は json と比べてどうセキュアですか？という質問に回答できなくて（論破されて）悔しかったのか。