Q&A
なぜか初心者ほどECサイトを作りたがるけどまともなプログラマー・エンジニアになるほど「他人のお金を扱う責任の重さ」を分かってるので避けるようになる。
ECサイトを作ってます。
LaravelでCRUD処理を実装をしていますが、UPDATEやDELETEはIDを渡す必要があるため、GET方式で送る処理を書きました。このやり方でセキュリティ的に問題ないのでしょうか。
自分が学習したサンプルでは、POSTで送っており、csrf_field() というセキュリティ対策っぽいタグも入っていましたが、GETの場合は特に何もなく不安に思いました。
GET送信でも特に問題はないのか、教えて頂けると助かります。
ちなみに、POSTだとformを使用するため、レイアウトに問題が出てしまいました。
ありがとうございます。チュートリアルではほとんどコピペで書いたので、リソースコントローラの重要性にまったく気付けませんでした。大事なところなので、よく読んで理解して進めたいと思います。
チャレンジするには早すぎるから無料のQA使うぐらいなら辞めときましょう。それが身の為です。
どうしても今の力量でチャレンジしたいならまともな技術者を雇わないとアウトでしょう。
なお、無知な人が安易にシステム作って負債を追うのは可哀相だと思ってのアドバイスですので、聞く耳持たなくても結構です。
質問編集されて変わってるけど、上のコメントは初心者がECを作ろうとしていた事に対しての助言なのでECでないのなら特に外部委託したり技術者を雇う必要はありません
「初心者がECサイトを作る」と書くとかなりの誤解を招くとわかったので説明させて頂きます。
実はすでに一人プログラマに協力して頂いており、アドバイスを頂きながら外注と採用を平行ですすめています。
ただ、人に任せるといっても自分でわかっていないとまともなものが作れないので、一度自らコーディングしている状況になります。
無知な初心者が自分で作ったものをそのまま公開したりはしないのでご安心ください。
前提条件としてお伝えした方がよいと思い書きましたが、逆にみなさんをびっくりさせてしまったようです。
また、「EC=決済」というイメージを持つ技術者が多いのかもしれませんが、ECサイトの決済周りは決済代行会社の領域ですので、ECサイトが決済機能を自前で実装することはほとんどありません。外部サイトに飛ぶか、お客様が入力した時点ですでに暗号化された情報をAPIで送信します。
GMOペパボの「カラーミー」ですら、いまだにカード情報は自社のシステムには保持しない仕様になってます。それはユーザビリティ（利益）を捨ててでも、セキュリティのリスクを回避したいという判断になります。
ですので、いくら「初心者がECサイトを作ります」といっても、「決済機能を自前で実装してカード情報が流出して大惨事になる」という状況は実際にはなかなか起こりえないのかと思います。
ただ、個人情報の流出は普通に起きるので、ECサイトではないにしても、最低限のセキュリティの知識は必要だと思っています。
ただ、経営者がゼロからフレームワークまで勉強して自らコーディングするのはなかなか大変な作業でして、外注とか採用を考えると逃げ道になってしまい、一旦は「自分で作る」という強い気持ちにならないと、心が折れてしまうのかもしれません。
なので、今後も対外的には「初心者が自力で作ります」というかもしれません。
回答4件
0
Laravel で2日くらい前から作り始め、とりあえずの商品マスタのCRUD処理を実装をしていますが、UPDATEやDELETEはIDを渡す必要があるため、GET方式で送る処理を書きました。このやり方でセキュリティ的に問題ないのでしょうか。
実装によっては、問題が発生します。
Laravel 以前の問題です。
設計に対しての基礎的な知識が必要です。
実際に公開し運用するシステムのため、
EC サイトは初学者が設計するのは無理です。
識者に合流してもらい、適切なアドバイスを求めてください。
投稿2021/02/27 23:42
退会済みユーザー
総合スコア0
ありがとうございます。すでにPHPで最後まで作ってあるので、仕様的な設計は終わってるのですが、セキュリティ的なことを踏まえた設計という意味でしょうか。Laravelの基本的な機能に忠実に従って作れば大丈夫か、アドバイザーのプログラマに確認してみます。
Laravelの勉強ばかりしても身にならないので、実際に作ってみました。
何回作り直しても良いですし、もちろんそのまま公開したりはしないので、とにかく実践的に進めることにより、学習したかったのです。大変勉強になりました。ありがとうございます。
> すでにPHPで最後まで作ってあるので、仕様的な設計は終わってる
Laravel の問題ではないので、この質問が出る状態であれば設計に問題があります。
> アドバイザーのプログラマに確認してみます。
プログラマではなく、上流工程をアドバイスできる方に相談してください。
サイト設計とかセキュリティポリシーとかその辺の話になります。
かなり経験豊富なプログラマにアドバイスを求めているつもりでしたが、サイト設計やセキュリティについてどの程度の知識があるか、素人が判断するのは難しいですね。複数の人に聞いてみたいと思います。ありがとうございます！
プログラマーに設計の責務を負わせるのは間違いです。
企画段階で法律との整合性をとりデータモデリングする中で業務分析が必要となるので、初学者で経験がないのであれば EC に特化したコンサルと相談してください。
自身でも学習する必要があると思いますが、法律調査が最初の一歩になるので最初に見るべきはこちらかなぁ。
https://www.meti.go.jp/press/2019/12/20191219003/20191219003-2.pdf
EC は制限が厳しい分野の一角なので、正しく認識したうえでチャレンジしてください。
UI にすら法的根拠を求められる世界です。かなりしんどいですよ。
法律との整合性ですか、。全然考えたことありませんでした。
（いろいろと詳しく書きましたが、火に油なので削除します）
最終的には外注するか、プログラマを雇うかになると思いますが、とりあえず自分で作ってみて、フレームワークやその他のことをできるだけ理解したくてコーディングしてみているという状況でした。
なんか色々突っ込みたくなるコメントですけど、EC サービスの提供が目的なら、コーディングして研究するより上流工程を体系的に学んだ方が現実的ですよ。
あと、EC 系の脅威情報やセキュリティ要件/設計情報は表に出てくることがほぼ無いので、独学で何とかするのは無理です。企画段階から、その辺の情報を持っている人に合流してもらってください。
そうなんですね、タイミングが来たらセキュリティ専門の会社に聞いてみます。
来週、受託会社と面談がありますが、お話を聞く限りうちでは無理ですといわれるのでしょうかね？興味深いです。
0
ベストアンサー
CSRFについて学ぶ必要がありそうだと感じました。
まず、CSRF TOKENとはなんのためにあるんでしょうか？
大雑把に説明します。
CSRFに脆弱なKwitter（Twitterじゃないですよ）と、攻撃したい人が立ち上げたCwitterがあったとしましす。
通常、Kwitterには、Kwitterへのログイン後にKwitterのフォームから投稿内容を送信する必要性があります。
そこで、Cwitterと言うサイトが以下のようなフォームを設置したとします。
html
1<form action="KwitterのPOST URL"> 2 <input type="hidden" name="body" value="ﾀﾋね！〇〇！" /> 3 <button type="submit">今だけお得なセール！！</button> 4</form>
どうでしょう。もしも、Kwitterにログインしている人が、「今だけお得なセール！！」につられて送信ボタンを押したら。
Kwitter側に誹謗中傷の内容のメッセージが意図せず投稿されてしまいますよね？
もしもこれがECサイトの購入フォームなら？それを防ぐのが、CSRF TOKENです。
めっちゃ総じると、「自分のサイトからの送信内容であることを確認する」のが、CSRF TOKENです。
大体、CSRFについて解説したところで。
これって、GETで必要でしょうか？
自分のサイトからのアクセスを確認する必要ありますか？
だから、デフォルトでGETにはCSRFは用意されていません。
で、GETで機密情報を送っていいのかと言うご質問ですが。
「内容による」としか言いようがありません。
が、一般的にその情報が第三者に漏れて著しい問題がある内容ならGETは使うべきではないでしょう。
GETは、アクセス履歴に残ります。もしも、GETにクレジット番号がついていたら。。
アクセス履歴を見ればその人のクレジットを使って本人以外が決済できてしまいますよね。
逆に、商品一覧ページ（誰でもアクセス可能）での検索はどうでしょう？
別に検索内容が第三者に漏れて問題はあるかというと、ありますがそれが著しく利用者に不利益をもたらすと言うわけではないでしょう。第一、リンク共有したいと言うニーズもあるのでそれは逆にPOSTを使うべきではないでしょう。
少し長くなりましたがこんなところです。
基本的には、ECサイトの会員系の処理はPOSTを使った方が良いですが、GETを使える場合もあります。
余談ですが、GETはアクセス、POSTは送信と言う方が少しわかりやすいのかなぁ、と。
投稿2021/02/28 11:58
編集2021/02/28 12:03
総合スコア10429
ご丁寧かつ大変わかりやすい回答を頂き、ありがとうございます。
今作っている部分は、管理画面の商品テーブルなので、GETでも大丈夫な気がしてきました。
ただ、今回で自分には基本的なセキュリティの知識がごっそり抜けていて、いろんなことが判断できない状態にあるとわかったので、セキュリティについて一通り勉強をしたいと思います。
「安全なWebアプリケーション」の作り方 3,200円
複数の方にこの本をおすすめ頂きました。
> 今作っている部分は、管理画面の商品テーブルなので、GETでも大丈夫な気がしてきました。
ひとつ注意していただきたいのですが、「大丈夫」かどうかを決めるのは、「質問者さん」ではなく、「要件」です。
あともうひとつ。
クソみたいなスタイルで逃す機会の損失と、
損害賠償による金銭的・社会的損失のどちらが大きいのかを比べれば自ずと答えは出てくると思います。
要件・・・すみません、今の自分には頂いたアドバイスの意味がよく理解できませんでした。
他の方の回答で、「処理はPOSTで表示はGET」と言われても「？？？」という感じでした。
GETとかPOSTとかHTTPとかレスポンスとか、この辺のことを勉強したことが一度もないので、本来必要な前提知識が抜けているのかもしれません。
「Webを支える技術」も注文してみました。
確かに、致命的なリスクが存在する場合は、コストをかけてでも回避する必要がありますね。
0
ちなみに、UI/UXにもかなりこだわっているため、POSTだとformを使用するため、ボタンの配置のレイアウトに問題が出てしまいました。
商品一覧の右側にボタンを配置するため、スペース的にかなりギリギリの配置をしております。
これが理由で、GETにするなんていう選択をするようであれば、単純に技術力不足です。
POSTというか、Laravel 標準の Route::resource() が提供する。RESTの使用に従うべきです。
投稿2021/02/28 04:17
総合スコア3923
やっぱり勝手に改造してGETにしたらダメみたいですね。質問してよかったです。
チュートリアルをやっただけだとわかりませんでしたが、resource って大事なところなんですね。RESTですね、青本にその項目ありました。よく読んで理解して進めたいと思います。
ありがとうございました。
0
PDATEやDELETEはIDを渡す必要があるため、GET方式で送る処理を書きました。
編集対象取得表示ページはGETとして、実際の処理時はPOSTでリクエストすれば良いのでは。
POSTだとformを使用するため、ボタンの配置のレイアウトに問題が出てしまいました。
レイアウトの調整はいくらでもできるかと思いますが、
form置きたくないならAjaxなどで非同期で更新すれば良いのでは？
投稿2021/02/27 23:29
編集2021/02/27 23:29
総合スコア80875
表示ページはGETで取得はPOSTということができるのですね。ありがとうございます。調べてみます。
みなさんの回答を聞いて、チュートリアルでやったresourceがLaravelの基本的かつ大事な部分とわかったので、レイアウトの調整をしたいと思います。
あとは、Ajaxですね。ありがとうございます。調べてみます。
>表示ページはGETで取得はPOSTということができるのですね
あくまで「リクエストの一種」ですよ。
そのように書いたらそのようにリクエストされます。
そうなんですね。サーバとの応答みたいな基礎的な知識がないまま進めているので、つまるところも多いのかもしれません。一度やらないとですね。
「リクエスト」と「レスポンス」はWeb関係なく出てくる要素なので必須です。
Webはそのあたり明確になっているとも言えます。
むしろ、フレームワーク触る前に理解しておくべき部分でもあります。
フレームワーク使ってるという時点で「それなりに元の言語は理解できてるんだろうな」という前提で回答者は見ますが、そうでない質問者が多い現状は非常によろしくないですね。
Ruby on Railsならともかく、PHP関連のフレームワークは言語知識、Web自体の知識は相当以上に必要です。
Laravelのテーマは「Web職人のための」ですからね。
やはり必須なんですね。「Webを支える技術という本」を買ってみます。
Twitterでいろいろ聞いてみると、teratailには無知すぎる初心者が多く、風当たりが強いようですね。
経験豊富なエンジニアの方から見ると、自分も無謀な初心者に見えるかもしれませんが、不足している基本的な知識を早急に習得し、質問の仕方に気を付けてご迷惑をかけないように頑張ります。
「Web職人のための」ですか。初心者向けではないのですね。
>teratailには無知すぎる初心者が多く、風当たりが強いようです
ここに大きな勘違いが生まれていますが、技術的な初心者なら別に問題はないです。
ルールぶち破って自分ルールを押し通そうとする社会的に疑問な人が問題です。
中には「自分ができないのはお前らのせいだ」のような横柄な態度の人までいる。
実際に技術的に明らかに初心者でも質問内容しっかり書けていたり指摘を受け入れたり
意欲が見える人はどんどん解決していき、気づけば質問しなくなっていっています。
＞「Web職人のための」ですか。初心者向けではないのですね。
https://laravel.com/
タイトルにうたわれています。
The PHP Framework for Web Artisans
そうなんですか。自分は回答したことがないのでわかりませんが、それはひどいですね。
自分もしっかりルールを守り、指摘を受け入れて成長していけたらと思います。
Artisanの意味は気になって調べましたが、そこに繋がるんですね。
たまに興味あるカテゴリの質問を回答してみるつもりで見てみたら良いかもしれません。
実際に回答はしなくても、回答のために何が必要か見えてくることもあります。
それで言うと「質問テンプレート」と「質問するときのヒント」は非常によくできていることが分かります。
なるほど、それは参考になります！確かに逆の視点を体験する必要ありますね。
せっかくの有益なサイトなので、ちゃんと理解して有効活用したいと思います！
ありがとうございます！
ここ何年かそのように前向きな反応してくれる質問者が激減しているので
頑張ってほしいと思います。
え、そうなんですか！
無料でこんなにアドバイスを頂いて、システムにも回答者様にも感謝しかありません！
フレームワークの勉強がまったく進まず１ヶ月苦しみ、スクールやMENTAも検討しましたが、
teratailが圧倒的に解決が早く、学習効率が劇的に上がりました。
本当に感謝です！頑張ります！
>スクールやMENTA
相性はあります。方針に自分が合うかもあるでしょうし。
＞teratailが圧倒的に解決が早く、学習効率が劇的に上がりました。
釘を刺すようで申し訳ないですが、teratailにも先に挙げたようなルールは
サイトとして明示されているので、特に「推奨していない質問」にならないようには気を付けてください。
たぶんそのあたりは、他の質問をよく見ていくと分かる点も多いかと思います。
>サイトとして明示されているので、特に「推奨していない質問」にならないようには気を付けてください。
自分の目的のためだけに、他人のリソースを無駄に割いてはいけないということですね。
はい、ここ一番気を付けます！
ちなみにですが、「質問するときのヒント」がなかなか探せなくて、googleから検索しました。
大事なコンテンツだと思いますが、初心者がほぼ見ないところにあるのも、問題のように思います。
運営に要望を出してみます。
> teratailには無知すぎる初心者が多く、風当たりが強いようですね。
これは多くは２パターンに分かれると思うけど、一つ目は自分で調べも試しもせずに????な質問する奴で、これは質問画面や質問するまでに書かれている各種文章を無視して投稿していると思えて悪意を感じるので、辛辣なコメントが来ても仕方がない
試すってのはプログラムの場合は調べた結果とそれ以外の多数パターンを何度も実行した結果で判断する事です
もうひとつはそこまで悪気が無いんだろうけど基礎知識が無さ過ぎてそのままだとお前大怪我するぞって問題、口が良いか悪いかは別としてそこに対してモノを言うのは多くの場合はただの親切心だと思いますよ。少なくとも自分の場合はそうですし。
修正欄のコメントまで編集されちゃってるのでチャレンジどうだ言ってる自分のコメントは最早意味不明になってますが、チャレンジするなら痛い目見ないレベルから試したら？と思いますよ 痛い目見て学習しても良いけど、痛い目の度合いが分からないでしょ
他人の情報を預かる場合は取り返しがつかない事態になりますからね。
セキュリティ云々より法律の観点も必要になる。ISOも知識だけじゃなく認証取得も視野に入れておく必要がある。
学習のためで、ローカルに単に作ってみるくらいなら誰にも迷惑かけないので良いですけど、実際に公開したり、個人情報を預かるようなものを想定しているのなら話は違ってきます。
>初心者がほぼ見ないところにあるのも
「ヘルプページ」から行けますし、取扱説明書を見ないで使うのはとても褒められたものではないです。運営のせいにはできない。
ここ1年かそれくらいからですが、質問投稿前に1つチュートリアルに近いページを挟むようになりました。それすらも見ずに投稿してる人は非常に多いですね。
そこにあるものを見ずに自分がやりたいことだけを先行していては、作りたいものは到底作れるようにはなりません。
書いたとおりにしか動かないプログラムの世界ではドキュメントが絶対で、ドキュメントを無視する性質はプログラミングをしていく上では致命的とも言えます。
自ら考える、論理的思考を何よりも必要とする世界なので、なんでもそこにある親切に提供してもらえる
みたいな、お客様思考
昨今のソシャゲのようなものは期待しないほうが良いです。
エンジニアとしては成長しません。
あなたの回答
tips
プレビュー
