  |
はてなキーワード: CSRFとは
取り上げた技術は、本格的な開発でも役に立つもので、最も学習コストが低いものを選んだ。
重要度が低いものは載せていない。たとえばHTMLとCSSなんてググりながら書けば全く問題ない。Bootstrapなどのフレームワークも全くやる必要はなく、仮に就職先で使っていたら覚えればいい。
逆に言えば以下に挙げる技術は、そもそも概念自体がプログラミングにとって普遍的なものであり、（基礎的な部分を）調べながら使うようではエンジニア失格ということ。
基本的に現在では、バックエンド・フロントエンド・運用保守全てができないエンジニアに価値は無い。
以下に挙げた技術（①⑤⑥は他の言語やフレームワークで代替可能）が身に付いていなければまともな企業に就職することは難しい（もちろん、下らない業務システムを下請けで作ってる底辺企業には入れるだろうが）。
経験者でも、これらができない/わからないのは、相当恥ずかしいことだと思った方がいい。
特定の言語やフレームワークの書き方を知っていること自体に意味は無い。
重要なのは、他の言語やフレームワークにも共通する基礎を理解すること・保守性やセキュリティなどの品質を高める使い方ができること。
この2つは習得が容易だし、今覚えておけば向こう10年腐ることはないだろう。
基本的な構文や、よく使う標準ライブラリは勿論、高階関数・クラス・非同期処理等の発展的な機能も知り尽くしていなければならない。
言語のみではなく、パッケージ管理、単体テスト、タスクランナー等の周辺ツールの使い方も熟知している必要がある。
また、「リーダブルコード」や「コードコンプリート」に書いてあるような良い作法も身に付ける必要がある。
Gitを使えないのはプログラマーとして論外。細かい機能は調べればよいが、
多くの場合、本番環境やテスト環境はLinuxサーバーであるから、以下のような基本的な概念と使い方を知っておく必要がある。
環境構築、CI、デプロイなどは、現在コンテナを使って行うことが当たり前になっている。
これも細かいことをすべて覚える必要はないが、Dockerfileの書き方や、docker-composeの使い方などは知っておかなければいけない。
Flaskは、数あるWebフレームワークの中で最も簡単。本当に呆れるほど簡単で、Pythonさえ書ければすぐにアプリを作れる。
フレームワークを覚えること自体が重要なのではなく、Web開発の基本を習得することが重要。HTTP、ルーティング、データベース、SQL、認証、セッション管理などは当然すべて覚える。
データベースは、就職したらMySQLやPostgreSQLなどを使うことが多いかも知れないが、今はPythonの標準ライブラリにあるSQLite3を使えば十分。
作ったアプリを公開したければ、「Heroku」などにデプロイするのが良いだろう。
ブコメで指摘をいただきました。HerokuではSQLite3は使用できないようです。公式のドキュメントに従ってPostgreSQLを使用して下さい。
SQLite3はファイルにデータを持てる簡易DBなんだけど、Herokuにデプロイしてもストレージ的な使い方はできないから、結局PostgreSQLを使う必要あるから注意してね。（DAOを丸ごと書き換える羽目になる）
参考: https://devcenter.heroku.com/ja/articles/sqlite3
今の時代、フロントエンドをフレームワークなしで作るのはただのバカ。
2021年現在、実用的なフロントエンドのフレームワークはReactとVueしかない。Vueの方が少し簡単なのでこちらを選んだが、JavaScriptをしっかり理解しているなら大差は無い。
フロントエンドには膨大なパッケージ群があって全部覚えるのは大変だが、とりあえずまずはVueを完璧に使えればいい。Webpackの設定などは既存のものを流用すればいい。
アルゴリズムは全てのコンピュータ技術の基礎であり、絶対に知っていなければならない。
高速フーリエ変換のような高度な数学は必要ないが、クイックソートや木構造のような基本的なアルゴリズムは当然、その性質を知っていなければならない。
それらは言語の組み込み関数や標準ライブラリでも使われており、理解していなければ、それらの機能を正しく使うことができない。
また、プログラムを読み書きする際には、そのコードの計算量を見積もれなければならない。
セキュリティは言うまでもなく学ばなければならない。
有名な脆弱性や攻撃手法（XSS・SQLインジェクション・CSRFなど）が何だか理解していて、その対策を実装できなければならない。
各種暗号化技術や署名などについても、実装の詳細は知らなくていいが、共通鍵暗号や公開鍵暗号などの特性は理解する必要がある。
https://qiita.com/HirotoKagotani/items/181052eb85b686783806
なんでGET？
まぁわかる。糞実装すぎる。でも引き継いだ人に言うことではないでしょう。
POSTだと事故る
少なくとも今回のURL補完&直接アクセスの問題は起こらなかった。
規模的にも会社内で使っているだけのシステムだから別にPOSTに直すだけで問題解決する。
たしかにブラウザ機能でPOST再送も可能だけど、一年に一回しか実行しないURLのPOST再送が、登録データが溜まった頃に発生してしまうなんてシチュエーションはどだい考えつかない。一年間も削除完了しましたページのタブを温存し続けるとか？
たまたまそのタブをクリックしてPOST再送しますか？のダイアログに「はい」するの？その発生ケース本気で言ってる？ありえないだろ…
コンテキスト無視して一般論でドヤってんじゃねーよ。一般公開するシステムなら当然POSTにすれば問題解決なんて言語道断だが、システムがなんのためにどこで誰に寄って使われるかぐらい把握しろよ。杓子定規すぎるだろ
会社内でしか動いてないシステムにハッキングもクソもなく、LAN内に入られた時点でうんこセキュリティです。
社内だから適当に作って〜って言われたら、気を抜いちゃうと自分も似たいようなの作ってしまったかもしれない。
全人類が最低限、書き込み処理はPOST(or PUT DELETE)、読み込み系はGET、みたいなのだけでも切り分けておけば、平和になりそうだけど、人類は基本的に愚かなので、悲しい事件は減らないだろうな
| 時間 | 記事数 | 文字数 | 文字数平均 | 文字数中央値 |
|---|---|---|---|---|
| 00 | 107 | 12274 | 114.7 | 51 |
| 01 | 77 | 12458 | 161.8 | 52 |
| 02 | 66 | 7284 | 110.4 | 45.5 |
| 03 | 33 | 4569 | 138.5 | 53 |
| 04 | 8 | 1791 | 223.9 | 66 |
| 05 | 19 | 5236 | 275.6 | 73 |
| 06 | 12 | 3032 | 252.7 | 98 |
| 07 | 32 | 1703 | 53.2 | 37.5 |
| 08 | 55 | 4303 | 78.2 | 39 |
| 09 | 106 | 9294 | 87.7 | 52 |
| 10 | 75 | 8919 | 118.9 | 60 |
| 11 | 150 | 16923 | 112.8 | 40 |
| 12 | 112 | 9157 | 81.8 | 44.5 |
| 13 | 100 | 12595 | 126.0 | 45.5 |
| 14 | 105 | 9430 | 89.8 | 49 |
| 15 | 74 | 7506 | 101.4 | 55.5 |
| 16 | 154 | 14910 | 96.8 | 56.5 |
| 17 | 199 | 29492 | 148.2 | 69 |
| 18 | 167 | 24119 | 144.4 | 55 |
| 19 | 165 | 19860 | 120.4 | 56 |
| 20 | 167 | 13946 | 83.5 | 52 |
| 21 | 139 | 12774 | 91.9 | 27 |
| 22 | 151 | 19866 | 131.6 | 41 |
| 23 | 202 | 25060 | 124.1 | 48.5 |
| 1日 | 2475 | 286501 | 115.8 | 49 |
CSRF(6), アルゴ(3), ホワイトシチュー(3), テネット(3), 雑事(3), 一夫多妻(21), 結果発表(5), 日本学術会議(4), 有刺鉄線(3), 一夫多妻制(8), 改姓(5), 雄(22), 清掃(10), セックスレス(8), 姓(7), 50代(12), 救済(13), for(10), 喪女(7), ハマる(8), 職歴(6), post(12), 穏やか(12), 1億(9), 産まれ(14), 女児(11), blog(14), 産ま(9), 選べる(8), 出産(20), 発狂(16), 非モテ(13), m(13), 美人(23), 優れ(12), 夫婦(19), 夫(26), 育児(15), 奥さん(12)
■詐欺まがいのAIベンチャーを辞めた人の話 /20201004132406(19), ■フェミが発狂する心理 /20201004095148(17), ■結婚して妻の姓になり7年がたった /20201004004630(13), ■生活保護の受給者がタバコ吸うって悪いことなんかな？？ /20201003151701(12), ■調味料かけると意識高い系に思われるのが癪 /20201004121920(11), ■ぶっちゃけITエンジニアで稼げるかどうかなんて運 /20201004173050(9), ■30歳すぎて中卒無職ひきこもりなんだけど /20201004062336(9), ■ /20201004121756(9), ■今月の固定収支について /20201004121140(8), ■anond：20201003151701 /20201003152413(7), (タイトル不明) /20111003232937(6), ■有刺鉄線の謎 /20201002193547(6), ■豆腐はなぜ足が遅くなったの？ /20201003195942(6), ■舐めてもいいもの /20201004000054(6), ■同人誌作ってたおばさんのとある反省文 /20201004102342(6), ■ちょっと聞きたい /20201004201652(6), ■やればできる，ってマジだからな /20201004115359(5), ■子どもを産みたくない /20201004090539(5), ■ /20201004015624(5), ■え、フェミニストって本気で「モノ扱いされない・消費されない」社会が来ると思ってるの？ /20201003230118(5), ■ /20201003213040(5), ■anond：20201004141831 /20201004160036(5), ■フェミニストの言い分だと /20201004162325(5), ■ネトウヨって差別用語なん？ /20201004171222(5), ■ダイの大冒険を規制しろ、アニメ放映してる場合じゃねぇから /20201003212041(5), ■ /20201004181503(5), ■カツオブシに代わる出汁 /20201004222039(5), ■増田にすら他人の個人情報を探るやつがいて怖い /20201004115014(5)
と思うじゃん、ベストアンサーへの指摘でotnさんも
とあるので、当時でもすでに出来ないと思う。(せいぜい4年前だし)
CSRF周辺の情報なんか、訳知り顔で語ってる記事多い割には、本質を整理出来てる記事あんまり見かけなくて
それこそセキュリティにありがちな「おまじない」的対処に終止してる感じが漂ってくるんだよね。
とにかくパスワードは定期的に変えなさい。みたいな盲信に見える。
もちろんトークン使う方法は確実だし、ユーザーにリファラ送信しろコラ！とか怒らなくていいし、うまく使えば多重送信の制御にも使えるから使いやすいけど、
CSRF対策=トークン必ず使う！みたいな思い込みを見かけると、本当にそのセキュリティ対策どういう仕組で必要とされてるのか、どのように作用してるのか、そういったことを理解してる？ってなる。
https://teratail.com/questions/26966
仕掛ける側が、自サイトに飛ばして JavaScript や Flashでリファラを書き換え送信したら、リクエストの強要ができてしまいます（＝攻撃者がリクエストを投げる人になる）
Flashは死んだので考える必要無いとして、JavaScriptでリファラを書き換えて任意のサイトに送信することはできるとか本当か？
ちょっと調べた感じだと最新ブラウザでは完全に塞がれているので、無理だと思う。
アドオンなら専用APIを使ってリクエストにプロキシーみたいな処理を割り込ませて、ヘッダー書き換えて送信する機能が作れるっぽいけど、
そんなのヤバいアドオンを入れちゃった時点でCSRF無関係にセキュリティヤバいのでサーバー側は想定する意味ないです。
やっぱりCSRFを実行させるためにリファラーを改ざんするの不可能な気がするので、リファラーのチェックだけでCSRF対応できる気がする。
もちろんユーザーが自分でリファラ送信を拒否する場合はあるけど、「うちのサービス使うならリファラ出せコラ」ってエラー出しときゃ問題ないだろ。
CSRF対策でググるとトークン使った方法ばっかり出てくるけど、別にそこまでやらなくてもいいのでは？って感じする。
CSRFを警戒するってことは変な情報をsubmitされたくないだろうし、submitを受け付けるAPIはPOSTとかで受け付けてるだろうし、
いきなり知らないURLのリファラ持っている(つまり外部サイトの)POSTリクエストとかが飛んできてる時点で、全部ヤバいので拒否っとけばいいんじゃねーの？
外部からブラウザ上でユーザーの処理にちょっかい出してリファラを偽装してPOSTリクエストする処理は出来ない(ブラウザで禁止されてる)ので、CSRF攻撃は防げる。
という認識なんだけど、どうなんだろう。
仰ることはわかりますよ。フレームワークを使いこなしているだけで、言語や理論を知った気になっているという指摘はわかります。
しかしながら現実問題、大多数が使っているフレームワークを使わないと CSRF や SQL インジェクションといった脆弱性に対して低コストで応対できる方法がありますか？まさか WAF でどうにかなるなんて、言いませんよね。今どきフルスクラッチでアプリ作れ、なんて逆に技術力がないとしか聞こえませんが。
ぶっちゃけ Ruby や PHP なんて、クライアントとサーバのデータを低コストで受け渡すだけのツールとしか思ってないわ。RDB や S3 といったドメインはストレージにより近いなにかだし、iOS/Android/ブラウザ もたかが Swift/Java/HTML+CSS+JavaScript をいじるだけじゃねーか。ウェブ領域はセキュリティ気にしないと死ぬから、むしろメンテされているフレームワークを更新し続けないと死ぬんだよ。自作やメンテしてないフレームワークを利用する方が気がふれているとしか思えませんがね。
ここ連日騒がれている7pay。
パスワードリセットリンク送付先のメールアドレスに対して設計上の問題で脆弱性が発覚して大変な事態に発展しています。
昨日の会見では社長のITリテラシ不足が露呈したり、サービス継続が表明されたりして、いわゆる「祭」の様相を呈しています。
また、会見内で「セキュリティー審査を実施した」と明言がされました。
https://www.asahi.com/articles/ASM745HHHM74ULFA01Y.html
セキュリティー審査を実施していたにも関わらず、何故今回の問題が見逃されたのか。
非常に稚拙な推測ですが個人的に考えられる可能性をまとめてみようかなと思います。
その名の通り、サービスローンチ前に実施する、脆弱性や問題がないかの審査の事・・・だと解釈しました。
一般的には脆弱性診断とかセキュリティ検査とも呼ばれています。私はこちらの呼び方の方がしっくりきます。
「実施した」とはいっても、どういった内容を実施したかはわかりません。
ただ、7payは「一般に公開する」「お金を扱うサービス」になるため、ガチガチな脆弱性診断を実施すべきでしょうし、実際に実施したのではないかと思います。
通常、脆弱性診断というと、以下のような項目があげられると思います。
抜け漏れあると思うけど、大体どこのセキュリティベンダーでも上記のような項目を診断しているんじゃないかなあと思います。
詳しくは各ベンダの診断内容のページを見てみると更に詳しく載っています。
LAC、CyberDefence、NRIセキュア、ブロードバンドセキュリティ、スプラウトなど。
ただ、今回の脆弱性診断が外部ベンダで実施されたのか、内部で実施されたのかはわかりません。
以下、推測をつらつら書いていきます。
脆弱性診断はモノによりますが、診断内容をマシマシにするとエラい額が掛かります。
Webサービス診断は見積もり方法が各社違ったり、ツールを使うか手動とするかによって金額も大きく変わってきます。
また、数量計算もベンダによってまちまちです。ページ単位であったり、画面遷移単位であったり、SPAであればAPI単位であったり、複合での計算だったりします。
お願いすれば見積もり時にステージング環境で動いているWebサービスをクロールして、各ページの評価を付けてくれるベンダもあります。
規模と見積もり内容にもよりますが、100～200万といったところでしょうか。
スマホアプリ診断は一本幾らという場合が多いような気がしますね。相場としては50万～100万程度でしょうか。
プラットフォーム診断も内容によるとは思いますが、大体100万くらいかなあと思います。
これ以外にWebSocketを使っていたり、別のサービスと連携していたりするとその辺りの通信も含まれてくるのでまた金額は上がる可能性もあります。
Webサービス200万、スマホアプリ(iOS、Android)100万*2、プラットフォーム100万とすると、500万円掛かるわけですね。
脆弱性診断をするだけでこれだけのお金が吹っ飛んでしまうわけです。
そしてこれをそのまま発注するかと言われると、多分しないでしょう。
セキュリティはお金が掛かる割にリターンが少なく、目に見える結果が必ず出てくるとも限りません。
経営層は中々首を縦には振らないでしょう。
会見でも明らかになったことですが、社長のITリテラシはあまり高そうにありません。
こうなると脆弱性診断の稟議を通すのは中々容易ではなかった可能性もありそうです。
また7月1日に間に合わせたようなところもあるっぽい(?)ので、開発側に資金を全振りしていた可能性もあり、診断に費用を掛けられなかったのかもしれません。
いずれにせよ、全く実施しないのはまずいし重要そうな部分だけピックアップして実施しましょうという話にはなるでしょう。
削れるものをあげていってみましょう。
例えば、iOS用スマホアプリは実施しなくても良いかもしれません。iOS上で動くアプリは確かサンドボックス構造になっているはずで、ローカルに何かしらのデータを持っていても外部からのアクセスは基本不可であるためです。確か。
そもそもスマホアプリ自体不要かもしれません。7payのサービスへのアクセス用インターフェイスとしてのアプリしか提供していないのであれば、取り扱うデータはほとんどないと考えられるためです。そのため、スマホアプリAndroidのみ、もしくは両方実施しなくても大きな問題は発生しないのではないかと思います。
・・・この辺り私の勘違いというか、「最優先でやるべきだろjk」といった考えがあれば指摘ください。
プラットフォームも、ベンダによりますが実施しなくとも良いとも思います。
ベンダの説明でも、主にポートスキャンをして、空いているポートに対してtelnetで色々したりするといった説明がなされたと思います。
Webサービスなら443と、空いていても80くらいしか外部には公開していないので、これは実施しないという選択をしても不思議ではないと思います。
サーバのコンフィグも、DocumentRootがおかしいとか致命的な設定ミスをしていない限りは見てもらう必要はないでしょう。
そもそも構築手順等はノウハウもあるでしょうし、わざわざ見てもらう必要性はほとんどないわけです。
ワイドショーでは「不正は海外IPからで、国外からのアクセスを許可していた」事が取り上げられていましたが、例えプラットフォーム診断をしていても、この辺りは指摘されなかった可能性があります。
実施していればもしかしたら備考レベルでの注意や、口頭で「国内のみに留めておいた方がいいかも」といったことは伝えられたかもしれませんが、「利便性」という観点から実行されることはなかったんじゃないかなと思います。
Webサービスですが、ログイン・ログアウト処理は必須でしょう。また、新規登録、情報変更、退会処理も重要です。
パスワードリセットはどうでしょうか。正直これも重要です。なので、ベンダに依頼するにあたってはここも診断対象としていたはずです。
ところで今回の件では協力会社について様々な憶測が飛んでいますが、NRI説が結構人気みたいです。
ただ、NRIにはNRIセキュアというセキュリティに特化した子会社が存在しています。
もし脆弱性診断をするとなった場合、そこを使わないという手はあまり考えられません。そもそも発注時にそれを見越して診断費も開発の見積もりに含まれているのではないかと思います。
ただし、セブン側が「脆弱性診断はこちら側で発注します」と言っていれば話は別です。
NRIセキュアは診断費用が高いらしいので、コストダウンするために別ベンダに診断部分のみ発注する可能性はあります。
別のベンダに発注したことで、抜け落ちた可能性はゼロではないかもしれません。
また、NRIセキュアが実施する場合においても、「ここは抑えておいた方が良い」という機能毎やページ毎にランク付けした資料をセブン側に提出することと思われますが、どこを実施してどこを削るかの最終的な判断はセブンに委ねられます。
考えられる事としてはパスワードリセットの処理を診断対象外としたことですが・・・そうする理由もわからないので、うーん・・・。
ただ、こうして対象を削りまくることで100万程度、もしくはそれ以下まで診断費用を抑えることができます。
使ったことはありませんが、SecurityBlanket 365というサービスは自動での定期診断が可能なようです。
ライセンスやどういった動き方をするのかはいまいちわかりませんが、ベンダに逐次依頼する脆弱性診断よりかは安く済むはずです。
ただ、自動診断となると設計上の不備やそれに伴う問題は検出できないはずです。
ツールの手が届く範囲での、XSSやPoC、ヘッダの有無など、ごく一般的な脆弱性診断になると考えられます。
でも手軽そうで安価っぽいなので、これで済ませていても不思議ではないです。
脆弱性診断ツールはOSSのものもあればベンダが販売していたり、SaaSで提供しているものもあります。
OSSならOWASP ZAPやw3afがWebサービスの診断が可能です。また、phpcs-security-auditなど、ソースコードを解析し脆弱な箇所がないかを診断するものもあります。
ちなみにWebサービスに対する診断を「DAST」、ソースコードに対する診断を「SAST」と言ったりします。
有償のものとなると、DASTは先程のSecurityBlanket、AppScan、Nessus、Vex、VAddyが挙げられると思います。
SASTになると、RIPS TECH、Contrast Securityなどでしょうか。
上記のようなツールを用いて、セブン内で脆弱性診断を実施することでセキュリティの知見を高めたり、内部で完結させるための動きを取っていたかもしれません。
こういった動きは結構色んな組織で見受けられます。外部の手を借りずに診断ができれば、関係者間の調整も楽ですし、それと比べると費用も安く済みますからね。
ただし、社内のエンジニアに任せる事になるため、片手間になってしまう可能性があります。
また、ツールの使用方法についてのノウハウは溜まるかもしれませんが、それとセキュリティの知見が溜まるかどうかは別の問題としてあると思います。
・・・とは言ってもセブンにはCSIRT部隊がちゃんとあるんですよね。
https://www.nca.gr.jp/member/7icsirt.html
『7&i CSIRT は、7&i グループの CSIRT として設置され、グループ企業に対してサービスを提供しています。』と記載があります。
また、『7&i CSIRT は、7&i HLDGS. の組織内に専任要員を以て設置され、インシデント発生時の対応だけでなく、インシデント発生の未然防止にも注力しています。
グループ企業の情報システム部門と連携し、7&i グループ内で発生するインシデントに対する未然防止のための調査・分析とリスク情報の共有、ならびにインシデント対応活動を行なっています。』
という記載もあるため、今回の7payも、7&i CSIRTが動いてセキュリティ関連のチェックをしていたのではないかと思います。「情報システム部門」とはありますが。
組織図上にはありませんが、デジタル推進戦略本部の下か、リスクマネジメント委員会、情報管理委員会のどこかに所属しているんじゃないかと思われます。
日本CSIRT協議会にも名を連ねているわけですし、CSIRTメンバーは専任要因ともありますし、セキュリティ関連の技術知識は十二分にあると思うんですよね。
なので、内部でツールを使って実施していたからといって、こんな重大な不備を見逃すというのはちょっと考え辛いなあ・・・と思います。
会見内で言われた二段階認証も検討事項に上がらなかったのかなあ・・・と。
で、これを書いている最中に気付いたのですが以下のようなリリースが出ていたんですね。
https://www.7pay.co.jp/news/news_20190705_01.pdf
これを見ると内部のCSIRTが機能していなかったか、力不足と判断されたかどちらかになるのかな・・・と。
実際はどうだかわかりませんけど・・・。
これも有り得る話かなあ・・・と。
開発やベンダやCSIRT部隊が情報共有したとしても、POが忘れていたとか、伝えたつもりが曖昧な表現で伝わっていなかったとか・・・。
ベンダが実施して指摘事項として伝えていたけど、いつの間にやら抜け落ちていてそのままサービスイン・・・というのもシナリオとしては考えられますね。
7payは社内的にも一大プロジェクトだったはずで、スケジュールも決まっている場合、余計なことを物申すと手戻りや対応に時間を取られることになります。
そういった事を許さない空気が出来上がっていると、まあ中々上には上がってきづらいです。
これも十分にありえる話ですかね。ないといいんですけど。
どうしても『審査』という言葉に引っかかっています。『検査』ならまだわかるんですが。
そこで思ったのですが、情報セキュリティ基本方針と個人情報保護方針を元にしたチェックリストのようなものがセブン内にあって、それを埋めた・・・みたいなことを「セキュリティー審査」と言っていたりするのかなと思ってしまったんですね。
でもこれはセブンペイの社長が個人情報保護管理責任者ということで、ISMSやPMS等で慣れ親しんだ単語である『審査』を使っただけかもしれません。
そもそもそれで終わらせるなんて事ないでしょう。セブン程の企業が・・・。
大穴ですね。いやこれはないと思いますよ。あったら大問題じゃないですか・・・。
というわけで、なんとなく「こうだったりして・・・」みたいな事をつらつら書いてみました。
そういえばomni7で以下のお知らせが上がっていましたね。
https://www.omni7.jp/general/static/info190705
『定期的にパスワードを変更いただきますようお願い申し上げます。』とのことです。CSIRTはもしかしたらもう機能していないのかもしれないですね。
もしくはわかりやすい対策を提示しろと言われたのかもしれません。それなら仕方ないんですけど。
以上。
一部typoとか指摘事項を修正しました(役不足→力不足 etc)。
ついでに時間経ってるけど追記します。もう誰も見ないでしょうけど。
ちゃんと読んでいただけましたか？全文通して私の主張が「監査をしっかりやれば防げた」という意味と捉えられているのでしょうか。そんなに分かりづらい文章を書いた覚えもないのですが・・・。
一番上でも記載していますが、私は今回の7payの「セキュリティ審査」は、「脆弱性や問題がないかの審査の事」、つまり「脆弱性診断」を指していると仮定して本エントリを書いています。
そういう意味で、ここで私が指している「審査」と貴方が指している「監査」は似て非なるものです。字面は少し似ていますがね。
監査は貴方の記載する通り「ある事象・対象に関し、遵守すべき法令や社内規程などの規準に照らして、業務や成果物がそれらに則っているかどうかの証拠を収集し、その証拠に基づいて、監査対象の有効性を利害関係者に合理的に保証すること」です。
貴方の言う「監査」に近いことは「セキュリティー審査自体が、情報セキュリティ基本方針と個人情報保護方針に沿った内容かどうかを確かめただけだった」の見出し部分で触れていますが、それで終わらせているわ Permalink | 記事への反応(2) | 05:48
いま、この「はてな匿名ダイアリーの自分の全記事を一括削除するスクリプト」は、動かない？
・POSTに与える最後の csrf を取ってくる parse が間違って、 rkm= が空になっている。正規表現で parse していたのを直して、 o+XXXXXXXXXXXXXXX/g を拾ってくるようにした。
・POSTに与える delete=が元々の %8d%ed%8f%9c%82%b7%82%e9 でも削除できないし、「 %e5%89%8a%e9%99%a4%e3%81%99%e3%82%8b 」でも削除できなかったし、これってマジックナンバーなん？
横増田も大歓迎です！貴重なご意見ありがとうございます！
もちろん、CSRFとかXSSとかDos攻撃とか、セキュリティ上最低限の対策は取るつもりですが、それ以外は良いね/悪いねの数で投稿を大きくしたり小さくしたり、ユーザー側で一日限りのidを毎回弾いてもらったりとか、「どっかで見たなそれ」的なことしか考えてません！
なるべく投稿の敷居を下げたいという思いがあるのと、あとは何より、アカウント情報の管理がめんどくさい！のです…
Twitter連携とかも今は簡単にできちゃうんですが、やりません！
とはいえ万が一軌道に乗るなんてことがあれば、アカウント制については考えなきゃいけない時期が来るだろうなとも思ってますー
そんな感じです！
俺、Macbook使ってるんすよ（タッチバー付13インチPro
俺、プログラミングスクールでプログラミング教えるアルバイトしてるんすよ（そいつはそのスクールの卒業生
懇親会で「皆さん嫌いな言語とかフレームワークはありますか？」と話題になると私は即座にRailsと言う。
「あのコマンドを打つと中で何が起きてるか知ってますか？」（知らない
「ActiveRecord？生でクエリ書いたことある？インデックスの意味くらい知ってるよね？」（書いたことない、適当なこと言う
3分後
「alert（'XSS'）」
百歩譲って学生エンジニアならまあセキュリティに無知なのは分かる。
しかしだな、文系エンジニアは「俺もハッキングしたい（笑）」な勢いで詳しく解説することを要求してくる。非常にウザい。
"
"
しょうがないので優しく解説すると「君ってハッキングとかしてそう（笑）」「君将来ハッカーになりそうだわ（笑）（クラッキング的な意味で）」
死ねよ。
俺、Git使って開発したんすよ（GUIのSourcetree
え？バグ？ちゃんとテストしたんだけどなぁ（完全手動テスト（）笑
AWSとGCPは登録はしたものの使い方が分からなくて結局放置
pwdとcdしか知らない（Makefileを作ったことないからいつもネットのコピペコマンド
はい、ゴールデンタイムに鯖落ち。復旧した時にはゴールデンタイム終了のお知らせ。
理由、CDNを刺してない、貧弱なプランの鯖（勿論ロードバランサなんか使ってない）
でも彼らは一応優秀な文系エンジニア。高学歴、サービスも作ったこともある、それなりの実績も持っている。しかし文系だ。
こういう奴らがいるからちゃんとしたエンジニアを軽視される。黙って営業職に転職してこい。
まあでも大学じゃ作者の気持ちしか考えてないのだから当然のなのかもな（笑）
追記
残念な理系名前を書くだけ一発採用派遣SIerは対象としてない。論外だ。
給料が安い？
そんなことは無い。400万以上貰える会社に内定もらっているから嫉妬も不満も特に無い。
だがしかし、ムカつく。
そんな奴が同期にいたら蹴り飛ばしてやりたくなる。
だが見てみろ、あいつらのアプリバックエンドが無いんだぞ？意欲は認める。だがそれで胸を張ってiOSエンジニアなんて無理があるだろ？
http://anond.hatelabo.jp/20160902031012
はてブで批判してる人たちよりよほど志のある学生さんだと思うので、いろいろ書いてみます。おっさんのたわ言ではありますが、元記事の人にすこしでもヒントになればと思って。
まず、日本の大学で勉強しても実用的なソフトウェアが書けるようにはなりません。どういうことかというと、「情報系の大学に行けば○○が作れるようになる!」という世間一般の期待と、実際に大学で教えている内容には大きなギャップがあるということです。
これは大学が悪いのではなく、大学はそもそもそういうものであって、それが世間に認知されてないというだけです。
具体的に挙げてみましょう。
大学で教えてる内容ってこんな感じなので、ゲームやアプリやサービスを作ることが目的の人から見ると、役に立たない内容にしか見えませんし、実際たいして役に立ちません。その証拠に、大学の情報系学科を出ていないのにゲームやiOSアプリやWebサービスを作っている人はゴマンといるし、逆に日本の大学の先生でゲームやiOSアプリやWebサービスを作れる人はほとんどいません。
これは重要なことなのでもう一度書きますが、日本の大学の先生でゲームやアプリやサービスを作れる人はほとんどいません。大学の先生が得意なのは、プログラムを書くことではなく論文を書くことです。論文のためにプログラムを書くことはありますが、あくまでおまけです。
そのため、大学で勉強してもゲームやアプリやサービスが作れるようにはなりません。だって教えている側の先生が、ゲームやアプリやサービスを作ったこともなければ、作り方も知らないんだから。
そういう経験のない人たちばかりですよ、日本の大学の先生って。そんな人たちの授業を受けて、アプリやサービスが作れるようになると思うほうがおかしいでしょう。
ためしに、先生方のTwitterアカウント名でGithubを検索してみてください。いまどきGithubにアカウントがないとか、あったとしてもTestCaseすらないコードとか、そんなものばかりです。「研究内容をライバルに知られるわけにはいかないからGithubは使わない」という言い訳する人がいそう。けど、本当はGitが使えないだけでしょ？
あるいは、先生方の個人ページや研究室の紹介ページを開いて、HTMLソースを見てみてください。doctype宣言がないとか、viewportの指定がないとか、Pタグの中にULタグを使ってるとか、そんなのばかりです。HTMLすらろくに書けない人が、Webアプリを作れると思いますか？きっとXSSもCSRFも知らないですよ。
ですので、そういうことを勉強したいなら、ベンチャーやIT系企業に入るべきです。大学でそういうことを勉強しようとしても、教えられる人がいないから無理。
（「大学はそんなことを教える場所ではない！」と怒る人いると思うけど、教えられる先生がいないという事実をごまかすために怒ってるだけだから。）
とはいっても、大学の先生がプログラムがいっさい書けないというわけではないです。彼らが得意なのは、コンパイラやインタプリタやOSやソルバを作ることです。これらも実用的なソフトウェアと言えなくはありませんが、ゲームやアプリやサービスとはジャンルが大きく違います。
そのため、大学の情報系学科に進めばコンパイラやOSや機械学習ライブラリを書けるようにはなるかもしれませんが、それはゲームやアプリやサービスではないので、繰り返しになりますがそれらを作りたい人には大学は向きません。
じゃあ大学で授業を受けるのってムダなのかというと、必ずしもそうではないです。
大学で教えている内容って、ゲームやiOSアプリやWebサービスが一通り作れるようになってから、その先を目指すときになって初めて必要になることが多いです。たとえば、
こういうときになって、初めて大学で教わった内容が生きてきます。逆にいうと、そういう状況にならないと、大学で教わった内容は生きてこないと言えます。（情報系の学科で学んでいるなら、ライブラリや言語やOSを「使う人」ではなく「作る人」にぜひともなってほしいですね。）
元増田は、社会に役立つ実用的なソフトウェアを作りたいようです。しかし残念なことに、大学が教えている内容はその目的には合致していないことを説明しました。
こういう事情なので、元増田には大学をドロップアウトしてIT系の会社に入社することをお勧めします。ドロップアウトが難しいなら、インターンやバイトでなんとしても入り込むことです。
入るべき会社は、教育に力を入れている会社です。20人未満の小さな会社では教育に力を入れている余裕はないので、小さな会社はやめたほうがいいです。簡単にぐぐってみたところ、はてなやPixivやクックパッドやDeNAやドワンゴは教育制度が確立しているようです（違ってたらごめん）。そういった会社に入ったほうが、大学の授業を受けるよりも、元増田の目的にかなうのは間違いありません。
そして何年か働いて、iOSアプリやWebサービスが一通り作れるようになったら、大学に入り直すことです。これはとても効果的なので、元増田には強くお勧めします。
上で説明したように、大学というところは、ゲームやアプリやサービスの作り方は教えてくれず、それらが作れるようになって初めて役に立つことを教えてくれます。そのため、元増田はIT系の会社に入ってアプリやサービスの作り方を勉強し、それらが作れるようになってから再度大学の門をたたくのが、いちばん効率的です。
なお繰り返しますが、入るべき会社は「教育に力を入れている会社」です。今のIT系企業では、インターン生を「格安で使えるバイト君」としか見なしていない会社が多すぎます。そういう会社は、コストが掛かることはいやがるので、教育もろくにはしてくれません。逆に教育に力を入れている会社では、インターン制度を「将来の戦力を選別する期間」と見なしています。
残念ながら、そういう会社は東京に集中しているようです。例外は京都のはてなくらいでしょうか。地方の大学生にとってはつらい現実なので、はてなやPixivやドワンゴは地方でのインターン開催をお願いします。あとレベル5は九大と九工大の学生を鍛えてあげてください。
余談ですが、学生さんにひとこと：
インターンやバイトで潜り込む先の会社を選ぶときは、就活と同じような時間をかけて選んでください。バイトだからとかインターンだからという軽い気持ちで会社を選ぶ大学生が多いから、それを食い物にしている悪質経営者があとを立ちません。インターン生が「格安の学生バイト」として使われている現状を是正するために、学生のほうでも注意してください。
ドロップアウトを進めた手前、書こうと思ったけど、長すぎるのでやめた。
リツイートが100超えたら書く。
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。
要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。
ここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここにお詫びと感謝を述べておきたい。
抽出条件だが、参考にできそうなコミットログを多く含んでいそうなリポジトリをGitHubのSTARの多い方からざっと目で見て適当に選び、それぞれ最新コミットから5000件抽出した（あわせて前処理として、コミットログ冒頭のタグ情報は消去した）。
atomのみ5400件抽出していたため、計25400件のコミットログがベースである。このうち、以下の条件に合致するものは参考例にすべきでないとして一律排除した。
こうして残った8540件を眺めながら、適当に切り出したのがこの用例集である。個人的に「うーんこの」と思った表現も、散見される場合は載せた。
ということで、以下用例を羅列していく。
以上の用例をふまえ、今回の参考ログ8540件から先頭の単語を出現回数で並べると次のようになった。
| Add | 1149 |
| Fix | 1014 |
| Update | 584 |
| Remove | 566 |
| Use | 382 |
| Don't | 260 |
| Make | 228 |
| Move | 178 |
| Change | 103 |
| Rename | 85 |
| Improve | 76 |
| Avoid | 68 |
| Allow | 65 |
| Implement | 60 |
| Handle | 58 |
コミットログの基本形はもちろん動詞 + 名詞である。名詞は固有名詞、複数形、不可算名詞が多いが、単数形の場合の冠詞は a が使われるか、あるいは省略される。the はまず使われない。
何かを追加した、という表現では非常に広く Add が使われる。メソッドからテスト、ドキュメントに至るまで大概これでまかなえる。
一方、何かを修正した、という表現では広く Fix が使われる。「何か」は typo や crash といった単語からメソッド名まで幅広い名詞を取るが、動名詞はあまり取らないのと、that節は取らないのでその点は注意が必要である。
Fix は「何かが正しく動くようにした」ことを示し、正しい動作内容が何かを説明しない。そこで正しい動作内容に言及したい場合は Make sure が使われる（こちらはthat節が取れる）。ただし Fix よりもニュアンス的に重い表現と思われ、Fix を使わず Make sure ばかり使うのはちょっとキモいのではないかと思う（Ensure はさらに重い表現っぽい）。
また、Fix は typo 以外でのドキュメント修正に対して使われることは稀である。対して Update はドキュメント、コメント、テストに使われ、本体のコードの修正に対しては使われない。本体コードの修正にあわせてテストも更新したなら Update が使われる。ただ、テスト機構それ自体のバグを修正したなら Fix である。
無駄な何かを単純に除去したなら Remove を使う。これまでのもの(A)から別のもの(B)に切り替えたのであれば Use B instead of A か Change A to B が使われる。新たに何かを利用するようにしたのであれば Use を、利用を取りやめた場合は Don't use を使うことが多い。
何かをしないようにしたなら Don't を、内部実装の効率化なら Make A + 比較級/形容詞 か Improve が使われる。
中身の変更を伴わない単なる名前の変更なら Rename A to B、コードや機能の論理上の場所を移動させたなら Move A to B である。
この辺はリファクタリングと呼ばれる行為と思うが、Refactor というぼんやりした動詞はあまり使われず、このように変更内容の種類に応じて動詞が使い分けられている。
コミットログにはWhyを書くべきだ、というのを何かで見かけたので because とか since を使ったログがどの程度あるかを調べたが、8540件のうち22件だった。基本的に短く、シンプルに、一目で意味が取れるログが好まれる傾向がある。例えば get rid of とか2件しか使われておらず、圧倒的に remove である。
一方で、シンプルな単語だけど開始単語としては使われないものもある。例えば次のような単語である。Expand(9)、Extend(8)、Print(5)、Optimize(5)、Publish(4)、Append(4)、Modify(3)、Manage(2)、Revise(2)、Dump(2)、Insert(2)、Migrate(2)、Enhance(1)、Edit(1) 。いずれもカッコ内は8540件に対する冒頭での登場回数である。結局、より一般的で平易な単語で表せたり、Refactor同様に抽象度が高すぎると使われないのだろう。
8000件もログを見たおかげで、迷いなくコミットメッセージが思いつくようになったのが個人的には今回書いてて最大の収穫だった。たぶんカンニングペーパーを作る行為それ自体が効率のいい学習になるという話と同じだと思う。
このまとめも100以上用例を転載してあるので、それを読むだけでも多少は効果があるんじゃないかと思う。同じようにコミットログ書きたくねぇなぁ英語わっかんねぇなぁと思っている人にとって、何か役に立つところがあれば幸いである。
