「XSS」を含む日記 RSS

はてなキーワード: XSSとは

2019-09-13

anond:20190913123711

Web側で3層が完結する、ということは、フロントエンドだけでXSSが起こせる

いやXSSって入力手段があってアウトプットを適切にしてなければ起こるのであって3層関係ないでしょ

2019-07-06

7payのセキュリティ審査って何をやってたんだろうか

ここ連日騒がれている7pay。

パスワードリセットリンク送付先のメールアドレスに対して設計上の問題脆弱性が発覚して大変な事態に発展しています

昨日の会見では社長ITリテラシ不足が露呈したり、サービス継続が表明されたりして、いわゆる「祭」の様相を呈しています

また、会見内で「セキュリティ審査実施した」と明言がされました。

https://www.asahi.com/articles/ASM745HHHM74ULFA01Y.html

セキュリティ審査実施していたにも関わらず、何故今回の問題が見逃されたのか。

非常に稚拙な推測ですが個人的に考えられる可能性をまとめてみようかなと思います

セキュリティ審査とは

その名の通り、サービスローンチ前に実施する、脆弱性問題がないか審査の事・・・だと解釈しました。

審査」というとISMS辺りを連想しちゃいますね。

一般的には脆弱性診断とかセキュリティ検査とも呼ばれています。私はこちらの呼び方の方がしっくりきます

以後脆弱性診断と記載していきます

実施した」とはいっても、どういった内容を実施たかはわかりません。

ただ、7payは「一般に公開する」「お金を扱うサービス」になるため、ガチガチ脆弱性診断を実施すべきでしょうし、実際に実施したのではないかと思います

通常、脆弱性診断というと、以下のような項目があげられると思います

抜け漏れあると思うけど、大体どこのセキュリティベンダーでも上記のような項目を診断しているんじゃないかなあと思います

詳しくは各ベンダの診断内容のページを見てみると更に詳しく載っています

LAC、CyberDefence、NRIセキュア、ブロードバンドセキュリティスプラウトなど。

ただ、今回の脆弱性診断が外部ベンダ実施されたのか、内部で実施されたのかはわかりません。

以下、推測をつらつら書いていきます

外部ベンダ発注したが、コスト削減のために対象を削りまくった

脆弱性診断はモノによりますが、診断内容をマシマシにするとエラい額が掛かります

Webサービス診断は見積もり方法が各社違ったり、ツールを使うか手動とするかによって金額も大きく変わってきます

また、数量計算ベンダによってまちまちです。ページ単位であったり、画面遷移単位であったり、SPAであればAPI単位であったり、複合での計算だったりします。

お願いすれば見積もり時にステージング環境で動いているWebサービスクロールして、各ページの評価を付けてくれるベンダもあります

規模と見積もり内容にもよりますが、100~200万といったところでしょうか。

スマホアプリ診断は一本幾らという場合が多いような気がしますね。相場としては50万~100万程度でしょうか。

プラットフォーム診断も内容によるとは思いますが、大体100万くらいかなあと思います

これ以外にWebSocketを使っていたり、別のサービス連携していたりするとその辺りの通信も含まれてくるのでまた金額は上がる可能性もあります

Webサービス200万、スマホアプリ(iOSAndroid)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というサービス自動での定期診断が可能なようです。

ライセンスやどういった動き方をするのかはいまいちわかりませんが、ベンダ逐次依頼する脆弱性診断よりかは安く済むはずです。

ただ、自動診断となると設計上の不備やそれに伴う問題は検出できないはずです。

ツールの手が届く範囲での、XSSPoC、ヘッダの有無など、ごく一般的脆弱性診断になると考えられます

でも手軽そうで安価っぽいなので、これで済ませていても不思議ではないです。

セブン内部でツールを用いた診断を実施していた

脆弱性診断ツール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は社内的にも一大プロジェクトだったはずで、スケジュールも決まっている場合、余計なことを物申すと手戻りや対応時間を取られることになります

そういった事を許さな空気が出来上がっていると、まあ中々上には上がってきづらいです。

これも十分にありえる話ですかね。ないといいんですけど。

セキュリティ審査自体が、情報セキュリティ基本方針個人情報保護方針に沿った内容かどうかを確かめただけだった

どうしても『審査』という言葉に引っかかっています。『検査』ならまだわかるんですが。

そこで思ったのですが、情報セキュリティ基本方針個人情報保護方針を元にしたチェックリストのようなものセブン内にあって、それを埋めた・・・みたいなことを「セキュリティ審査」と言っていたりするのかなと思ってしまったんですね。

でもこれはセブンペイの社長個人情報保護管理責任者ということで、ISMSPMS等で慣れ親しんだ単語である審査』を使っただけかもしれません。

そもそもそれで終わらせるなんて事ないでしょう。セブン程の企業・・・

そもそもやってない

大穴ですね。いやこれはないと思いますよ。あったら大問題じゃないですか・・・

というわけで、なんとなく「こうだったりして・・・」みたいな事をつらつら書いてみました。

そういえばomni7で以下のお知らせが上がっていましたね。

https://www.omni7.jp/general/static/info190705

『定期的にパスワードを変更いただきますようお願い申し上げます。』とのことです。CSIRTはもしかしたらもう機能していないのかもしれないですね。

もしくはわかりやす対策提示しろと言われたのかもしれません。それなら仕方ないんですけど。

パスワード定期変更を推奨する因習はいつ消えるんでしょうか。

以上。

以下追記 2019-09-08

一部typoとか指摘事項を修正しました(役不足力不足 etc)。

ついでに時間経ってるけど追記します。もう誰も見ないでしょうけど。

所詮「人のつくりしもの」だよ

監査なんて取り揃えた書類通りになっているかどうかなので、監査受けているかセキュリティ的に大丈夫ってことじゃないよ

そんなに監査が万能なら監査できるくらいの人が作り出せば完璧になるはずだろ

ちゃんと読んでいただけましたか?全文通して私の主張が「監査をしっかりやれば防げた」という意味と捉えられているのでしょうか。そんなに分かりづらい文章を書いた覚えもないのですが・・・

一番上でも記載していますが、私は今回の7payの「セキュリティ審査」は、「脆弱性問題がないか審査の事」、つまり脆弱性診断」を指していると仮定して本エントリを書いています

そういう意味で、ここで私が指している「審査」と貴方が指している「監査」は似て非なるものです。字面は少し似ていますがね。

監査貴方記載する通り「ある事象対象に関し、遵守すべき法令社内規程などの規準に照らして、業務成果物がそれらに則っているかどうかの証拠収集し、その証拠に基づいて、監査対象有効性を利害関係者に合理的保証すること」です。

貴方の言う「監査」に近いことは「セキュリティ審査自体が、情報セキュリティ基本方針個人情報保護方針に沿った内容かどうかを確かめただけだった」の見出し部分で触れていますが、それで終わらせているわ このエントリーをはてなブックマークに追加ツイートシェア

2018-12-23

SECCON国内大会供養

SECCON国内大会お疲れ様でした

以下ツイッターなどから拾った我々の反省点となります

以上、来年もっと頑張ります

2018-12-06

NTT新卒で落ちました

NTT退職エントリ流行っているようなのでそもそも入れなかった人の話でも書きます

といっても1X年前の話です。

増田はどんなひとか

1980年台前半生まれ

リーマンショック直前の超売り手市場新卒4月初頭というゴールデンタイムNTT系列何社も受けて全滅したアホ。

趣味プログラミング。ICPFCとか参加したり小さいツールを書いたりしてた。

大学の専攻は数学日本ではやたら偏差値の高いらしいT大学に現役で入ってそのまま修士卒。

どこを受けたのか

NTT株、NTTD、NTTS、NTTH、NTTCなど。略称がどこを指すかは適当に考えてね。

部落ちてます4月はこのせいでお祈りされまくり、結局決まったのはNTT以外で夏ごろで。

なぜNTTに応募したのか

電話がとても好きだった。高校ぐらいのときモデムから高速リダイヤルをかけるアプリとか、

公衆電話の番号を探すツールとかを書いていた。PHS携帯が普及しだしたこから

そもそも仕様があまり手に入らなかったので興味を持てなくなった。113はよくお世話になった。

就活ときそのへんのことを思い出したのと、プログラミングが好きだったのでNTTなら

なにかできるんじゃないだろうかと思いたくさん受けた。

なぜNTTをそんなに落ちたのか

当時はプログラマというもの地位ものすごく低い時代だったと思う。

そんな時代に「プログラミングやりたいです。ICPFCとかめっちゃ楽しいです。」という割に

基本情報すらとっておらず、コミュ力も非常に低い上に専攻が純粋数学とか落ちて然るべき。

更にNTTがどういう人材を欲しているのかという企業研究もろくにしていなかったため、

自分御社にどういう貢献ができるのかを説明できず、ただやりたいことだけを喋っていたた。

また純粋数学研究内容の説明がしにくいというのはわかりきった話だったので、それは対策するべきだった。

面接でどんなこと聞かれたのか

NTT

3分研究内容を話すというプレゼンSPIがよかったらしく1次面接免除という連絡をいただき

喜んで2次面接に望んだところ純粋数学研究発表で、「この研究社会的意義はなにか?」という質問をされ無事死亡。

NTTD

書類審査で通過できず。

NTTS

社名にソフトウェアなんてついてるぐらいだからプログラミングガッツリできるんだろうと思い、

CPU命令セットの素晴らしさとその効率的エミュレータ実装について熱く話す。

面接官の「そんなことにしか興味ないんですか?」という返事は今でも覚えている。

NTTH

グループディスカッションで落ちる。コミュ力とか見られてたきがするが審査員は見てただけなので詳細は不明

NTTC

面接前に社員雑談する謎の時間があり、「T大の人、ぜひ来てほしいんですけどNTTDとかNTT株に

取られちゃって蹴られてしまうんですよね…」という話を聞く。その時点でDには落ちていたので苦笑いして面接へ。

当時盛り上がっていたNGN関係の話で面接官と盛り上がるも俺が考える最強の通信スタック実装法を

熱く語ってしまドン引きされる。

結局どこにいったのか

NTT系列はだめだったので結局某SIer就職年収は300万弱から5年ぐらい在籍しても500万弱ぐらいだった。

最初は流石に年収低すぎということで某Rエージェント転職活動をするもリーマンショック真っ最中

在籍も1年とかだったため「君なにしにきたの?」オーラがすごかった。その時点での転職は失敗。

SIerによくある通り仕事コードというものほとんど書かず、ExcelWordがメインであった。

ただ仕事自体は暇だったので、合間にひたすらProject Eulerをやっていた。

今は何してるのか

今はお仕事が変わり、AI関係ソフトウェアエンジニアみたいなお仕事をしている。

相変わらず面接ではコード書きたいですとかAtCoderとかの競技プログラミングの話しかしていないのだけど、

10年前に比べると反応がとてもよくなったと感じる。年収都内に何の不自由もなく暮らせるぐらいまでは

もらえるようになった。プログラマ地位は相当向上しているのではないだろうか。

個人的にはAtCoderTopCoderで黄~青ぐらいのプログラマ社会的地位10年で年収400万から1000万ぐらいまで上がった感じがある。

結局NTTにいったほうがよかったのか

退職エントリ読んでみると、NTT株は行ってみたかたかも。

ブコメへの回答

anond:20181206084718

今は1000万!と言いたいところですが、うまい棒5万本分ほど足りません。一本行けるように今後も精進します。

ただ今都内ソフトウェアエンジニアバブルといってもよく、かなり年収水準が上がっている気がします。

ですので多少は夢を持ってもよいのかなと。

回答追記

anond:20181206104025

キリの人も入社時は優秀だったんだと思います。あともし採用されるポテンシャルがあったとしても

ちゃん業界研究しないのはだめかと。いろいろな意味で私はだめでしたね。

id:ueno_neco

1990年代はまだ固定電話の古い交換器や緑・ピンク電話などが残ってた時代で、電話面白い挙動

NIFTY-SERVEフォーラム等で盛り上がっていた時代でした。そのため当時は同じような人が結構いました。

id:sny22015

うけてません。NTTの社風に合わないと全滅する可能性もあった(そして実際そうなった)ということで、

ある意味リスク管理ができていなかったとも言えます

id:shinobue679fbea

最近NTTDのOSS関係へのコミットは凄まじいですね。あの部隊尊敬しています

あのへんのコミッタ方たちはどういうルート採用されたんでしょうね?

id:ockeghem

大学時代XSSバイナリ解析に興味があったはずなのですが、就活ではその道は選びませんでした。

忘れていたというのもあるのですが、その数年前に日本セキュリティ系の団体ちょっともめてしまった

というのがあるのかもしれません。日本セキュリティ業界ちょっと前までアングラっぽい雰囲気

漂っていました(世界的にそうだっただけな感じもします)が、そんな方たちも某FF○Iとか某NAとか

ホワイトハッカー側で大きく活躍されてるようで、もしセキュリティ業界に身をおいていたら

そういう変化も楽しめたのかなぁとは思います

あ、徳丸さんのブログはいつも楽しく拝見させていただいています

id:Lumin

あの某NAのLuminさんでしょうか。当時はとても落ち込みましたが、今では楽しくやれているので

人間万事塞翁が馬というところかなと思います

2018-11-16

大臣現場のどこまで知っていればいいのか

USBXSSやらCTFになっていくのか?

国会質問できる人間もいなくなりそう

2018-07-17

大手ショッピングサイトXSSを見つけたんだけど報告すべき?

俺になにもメリットは無いけど

徳を積むために運営者にメールしたほうが良いのかなあ

2018-07-12

xss見つけたときの興奮

何に似てるかな

2018-05-29

XSSって無理じゃね?

ほぼ100%エスケープされてるし

出来たとしてもクッキーもhttponlyが主流だし

2018-05-14

例の大学ウェブサイト

ウェブアプリケーションXSS 脆弱性があるんだけど、IPAに報告してもネタとして喜びそうなので報告したくない。

2018-04-29

anond:20180429125147

こんにちは元増田です!

増田も大歓迎です!貴重なご意見ありがとうございます

荒らし対策については、実はあまり考えてません!

もちろん、CSRFとかXSSとかDos攻撃とか、セキュリティ上最低限の対策は取るつもりですが、それ以外は良いね/悪いねの数で投稿を大きくしたり小さくしたり、ユーザー側で一日限りのidを毎回弾いてもらったりとか、「どっかで見たなそれ」的なことしか考えてません!

なるべく投稿の敷居を下げたいという思いがあるのと、あとは何より、アカウント情報管理がめんどくさい!のです…

Twitter連携とかも今は簡単にできちゃうんですが、やりません!

はいえ万が一軌道に乗るなんてことがあれば、アカウント制については考えなきゃいけない時期が来るだろうなとも思ってます

そんな感じです!

2018-03-20

文系エンジニアなんて死ねばいいのに

文系エンジニアなんて死ねばいいのに

俺、Webサービス作ったんすよ(Rails

俺、iOSアプリ作ったんすよ(Swift

俺、Macbook使ってるんすよ(タッチバー付13インチPro

俺、プログラミングスクールプログラミング教えるアルバイトしてるんすよ(そいつはそのスクール卒業生

これぞ量産型文系エンジニア()

懇親会で「皆さん嫌いな言語とかフレームワークはありますか?」と話題になると私は即座にRailsと言う。

すると文系エンジニアはみんな嫌な顔をする。

そこでちょっとお話をすると皆怯んじゃう。

「あのコマンドを打つと中で何が起きてるか知ってますか?」(知らない

ActiveRecord?生でクエリいたことあるインデックス意味くらい知ってるよね?」(書いたことない、適当なこと言う

へーその作ったサービスURL教えてよ

3分

「alert('XSS')」

Session?Cookie?(何それどんな味のクッキー

CSRF?(企業理念か何か?

百歩譲って学生エンジニアならまあセキュリティ無知なのは分かる。

しかしだな、文系エンジニアは「俺もハッキングしたい(笑)」な勢いで詳しく解説することを要求してくる。非常にウザい。

"

お前はよぉ!自分で探すってことをできねぇのかよ!?

"

しょうがないので優しく解説すると「君ってハッキングとかしてそう(笑)」「君将来ハッカーになりそうだわ(笑)クラッキング的な意味で)」

死ねよ。

文系エンジニアはこれだけではない

俺、Git使って開発したんすよ(GUIのSourcetree

え?バグちゃんテストしたんだけどなぁ(完全手動テスト()

デプロイ先は9割Heroku。(HTTPS対応

AWSGCP登録はしたものの使い方が分からなくて結局放置

SSH証明書を使わずパスワードオンリー

pwdcdしか知らない(Makefileを作ったことないからいつもネットコピペコマンド

見た目重視のTerminal(ネットコピペ設定)

最近聞いた文系エンジニアもっと面白い

新規事業を開発してる文系エンジニア集団がいた。

開発は順調、プロモーションをかけていざリリース

はいゴールデンタイム鯖落ち。復旧した時にはゴールデンタイム終了のお知らせ

理由CDNを刺してない、貧弱なプランの鯖(勿論ロードバランサなんか使ってない)

噂による無線LANルーターの設定も出来ないレベルらしい。

でも彼らは一応優秀な文系エンジニア高学歴サービスも作ったこともある、それなりの実績も持っている。しか文系だ。

こういう奴らがいるかちゃんとしたエンジニアを軽視される。黙って営業職に転職してこい。

まあでも大学じゃ作者の気持ちしか考えてないのだから当然のなのかもな(笑)


追記

残念な理系名前を書くだけ一発採用派遣SIer対象としてない。論外だ。

給料が安い?

そんなことは無い。400万以上貰える会社内定もらっているか嫉妬も不満も特に無い。

だがしかし、ムカつく。

そんな奴が同期にいたら蹴り飛ばしてやりたくなる。

そうさ、今はSwiftiOS時代だ。

だが見てみろ、あいつらのアプリバックエンドが無いんだぞ?意欲は認める。だがそれで胸を張ってiOSエンジニアなんて無理があるだろ?

2018-02-28

せんぱいぷろぐらまーのおにいさまへ

おにいさまは言語文法を全部記憶しているの?

おにいさまは知らないことがあったとき英語公式リファレンスを調べているの?

おにいさまは英語論文を読んで情報収集しているの?グーグルスカラーを愛用しているの?

おにいさまは古典や名著といわれる本は読んでいるの?コードコンプリートは何周もしているの?

おにいさまはテスト最初に書いてるの?

おにいさまはコードを読みやすくするためにリファクタリングを完全にしているの?

おにいさまは要件定義も詳細設計も基本設計デザイン実装テスト保守もできるの?深夜も対応しているの?

おにいさまはセキュリティ対策も万全なの?xssもddosもへっちゃらなの?

おにいさまは手取り15万円なの?

おにいさま、すごい!

2016-09-03

http://anond.hatelabo.jp/20160902031012

http://anond.hatelabo.jp/20160902031012

はてブ批判してる人たちよりよほど志のある学生さんだと思うので、いろいろ書いてみますおっさんのたわ言ではありますが、元記事の人にすこしでもヒントになればと思って。

大学に行っても実用的なソフトウェアを書けるようにはならない

実務の話!! 実際に「IT系のおしごと」というのがやってるような話で、特にコーディングに直接絡んでくるようなもの

技術実態みたいなやつ。そういうのは学校で教わらないんですよね。

まず、日本大学勉強しても実用的なソフトウェアが書けるようにはなりません。どういうことかというと、「情報系の大学に行けば○○が作れるようになる!」という世間一般の期待と、実際に大学で教えている内容には大きなギャップがあるということです。

これは大学が悪いのではなく、大学はそもそもそういうものであって、それが世間認知されてないというだけです。

具体的に挙げてみましょう。

大学で教えてる内容ってこんな感じなので、ゲームアプリサービスを作ることが目的の人から見ると、役に立たない内容にしか見えませんし、実際たいして役に立ちません。その証拠に、大学情報学科を出ていないのにゲームiOSアプリWebサービスを作っている人はゴマンといるし、逆に日本大学先生ゲームiOSアプリWebサービスを作れる人はほとんどいません。

日本大学先生実用的なアプリサービスを作った経験がない

これは重要ことなのでもう一度書きますが、日本大学先生ゲームアプリサービスを作れる人はほとんどいません。大学先生が得意なのはプログラムを書くことではなく論文を書くことです。論文のためにプログラムを書くことはありますが、あくまでおまけです。

そのため、大学勉強してもゲームアプリサービスが作れるようにはなりません。だって教えている側の先生が、ゲームアプリサービスを作ったこともなければ、作り方も知らないんだから

そういう経験のない人たちばかりですよ、日本大学先生って。そんな人たちの授業を受けて、アプリサービスが作れるようになると思うほうがおかしいでしょう。

ためしに、先生方のTwitterアカウント名でGithub検索してみてください。いまどきGithubアカウントがないとか、あったとしてもTestCaseすらないコードとか、そんなものばかりです。「研究内容をライバルに知られるわけにはいかないかGithubは使わない」という言い訳する人がいそう。けど、本当はGitが使えないだけでしょ?

あるいは、先生方の個人ページや研究室の紹介ページを開いて、HTMLソースを見てみてください。doctype宣言がないとか、viewportの指定がないとか、Pタグの中にULタグを使ってるとか、そんなのばかりです。HTMLすらろくに書けない人が、Webアプリを作れると思いますか?きっとXSSCSRFも知らないですよ。

ですので、そういうことを勉強したいなら、ベンチャーIT系企業に入るべきです。大学でそういうことを勉強しようとしても、教えられる人がいないから無理。
(「大学はそんなことを教える場所ではない!」と怒る人いると思うけど、教えられる先生がいないという事実ごまかすために怒ってるだけだから。)

ジャンルが違う

はいっても、大学先生プログラムがいっさい書けないというわけではないです。彼らが得意なのはコンパイラインタプリタOSやソルバを作ることです。これらも実用的なソフトウェアと言えなくはありませんが、ゲームアプリサービスとはジャンルが大きく違います

そのため、大学情報学科に進めばコンパイラOS機械学習ライブラリを書けるようにはなるかもしれませんが、それはゲームアプリサービスではないので、繰り返しになりますがそれらを作りたい人には大学は向きません。

大学で教えている内容ってムダなのか

じゃあ大学で授業を受けるのってムダなのかというと、必ずしもそうではないです。

大学で教えている内容って、ゲームiOSアプリWebサービスが一通り作れるようになってから、その先を目指すときになって初めて必要になることが多いです。たとえば、

こういうときになって、初めて大学で教わった内容が生きてきます。逆にいうと、そういう状況にならないと、大学で教わった内容は生きてこないと言えます。(情報系の学科で学んでいるなら、ライブラリ言語OSを「使う人」ではなく「作る人」にぜひともなってほしいですね。)

元増田に進めたい進路

元増田は、社会に役立つ実用的なソフトウェアを作りたいようです。しかし残念なことに、大学が教えている内容はその目的には合致していないことを説明しました。

こういう事情なので、元増田には大学ドロップアウトしてIT系会社入社することをお勧めします。ドロップアウトが難しいなら、インターンバイトでなんとしても入り込むことです。

入るべき会社は、教育に力を入れている会社です。20人未満の小さな会社では教育に力を入れている余裕はないので、小さな会社はやめたほうがいいです。簡単にぐぐってみたところ、はてなPixivクックパッドDeNAドワンゴ教育制度確立しているようです(違ってたらごめん)。そういった会社に入ったほうが、大学の授業を受けるよりも、元増田目的にかなうのは間違いありません。

そして何年か働いて、iOSアプリWebサービスが一通り作れるようになったら、大学に入り直すことです。これはとても効果的なので、元増田には強くお勧めします。

上で説明したように、大学というところは、ゲームアプリサービスの作り方は教えてくれず、それらが作れるようになって初めて役に立つことを教えてくれます。そのため、元増田IT系会社に入ってアプリサービスの作り方を勉強し、それらが作れるようになってから再度大学の門をたたくのが、いちばん効率的です。

なお繰り返しますが、入るべき会社は「教育に力を入れている会社」です。今のIT系企業では、インターン生を「格安で使えるバイト君」としか見なしていない会社が多すぎます。そういう会社は、コストが掛かることはいやがるので、教育もろくにはしてくれません。逆に教育に力を入れている会社では、インターン制度を「将来の戦力を選別する期間」と見なしています

残念ながら、そういう会社東京に集中しているようです。例外京都はてなくらいでしょうか。地方大学生にとってはつらい現実なので、はてなPixivドワンゴ地方でのインターン開催をお願いします。あとレベル5は九大と九工大学生を鍛えてあげてください。

余談ですが、学生さんにひとこと:

インターンバイトで潜り込む先の会社を選ぶときは、就活と同じような時間をかけて選んでください。バイトからとかインターンからという軽い気持ち会社を選ぶ大学生が多いから、それを食い物にしている悪質経営者があとを立ちません。インターン生が「格安学生バイト」として使われている現状を是正するために、学生のほうでも注意してください。

大学で授業を受けなくても独学で効率的勉強する方法

ドロップアウトを進めた手前、書こうと思ったけど、長すぎるのでやめた。

リツイートが100超えたら書く。

2016-06-30

2016 年 6 月版初心者向け JavaScript セキュリティ

JavaScriptUI を構築していると XSS がうんたらかんたらみたいな能書きをきちんと理解してきちんとやっていくのが一番よいというのはそうなのですが、 2016 年にもなってそんなことの学習時間がしがし使うのもおかしい気がする。おかしい気がしないというそこのあなたCPUFlash ストレージから自作して現代風のシステム全部作っといてください。

というわけで初心者は以下の原則を守ればいいと思う

JSjQuery作業しない

PHP だけでなにかを作る人間はもうたぶんいないですし、 JavaScript での UI 構築ももうそういうものだと思っていいのではないでしょうか。 React か Angular かなんか使っとけばいいと思います。 React おすすめ。これらの現代っぽいフレームワークを使っている限り XSS のような初歩的なミスはほぼ起きません。 React の場合危険機能には Dangerously Set innerHTML というヤバそうな名前がついていて便利です。

同一ドメイン内に決済とかあるサイトに関してはもちろん上の原則はあてはまりません。それは初心者が触るべきものではない。

2016-01-07

XSS対策に別途金を請求する会社はくたばれ

掲示板ならXSS対策をして当たり前なんだよ。

何十万も請求しといてXSS対策をしないのは瑕疵だ。

2015-10-19

http://anond.hatelabo.jp/20151019114428

XSSとかの現状致命的な問題が見つかっていない点で、枯れていて、ソースに触れずにいたいのではなかろうか。

良かれと思って手を加えると、それはそれで新たなリスクが発生するからね。

2015-06-13

ハッカーに聞きたいんだけど

ハッカーはこのはてな匿名ダイアリーから個人情報を引っこ抜くことってできたりするの?ユーザー名とかパスワードとかそういうの。

XSSなりSQLインジェクションなりで。

いや別にしてくれというわけじゃないけどさ。

このサイトってどれくらいのセキュリティがあるのかなーって気になったんだ。

2015-05-04

http://qiita.com/ledsun/items/b9ea1a6426af8ca79381

この研修内容にはリストの部分にXSS発生するコードサンプルが含まれる。

新人研修をする人のスキルが低いのではないか。

2015-03-12

kanose が凄い?

http://anond.hatelabo.jp/20150312042513

いい加減なことを言って,はてサからちょっとあしらわれただけで火だるまになった id:kanose が?

id:kanose村長と呼ばれるようになったのは,並み居るはてな論客はてな内でのキャッキャウフフに興味がなかったからだよ。そういうネットでのコミュニケーションに興味ある界隈で位置取りが上手だったのは間違いないが,それだけのこと。政治でも IT 技術でもなんでもいいが専門的な界隈で id:kanose の影響力なんて皆無。だれが村長って呼びだしたのかは知らないが,その中身は空っぽしかない。

そもそもはてなに人が集まったのは,商業的な匂いがあまりしない雰囲気90年代ネットで育った人たちが馴染みやすかったこと。それからはてなダイアリーって名前からも分かるように,SNS どころか Web 2.0ブログって言葉一般的でなかった頃にユーザー同士のコミュニケーションに重きを置いたサービスを展開したこと。そういうネットでのコミュニケーションに注目した id:kanose には先見の明があったと思う。ただそれは村長って呼ばれるような実態じゃない。

ある意味村長って名称は秀逸で,いつの間にか一部ユーザーで村って意識が芽生えてその側面で語られるようになった。でもそれって現実を反映したものじゃない。たんに他人からそう見てほしい自分たちを描いたへたくそ物語再生産を続けてるだけ。

いい例がはてな村奇譚。はてなXSS といえば誰をおいてもまずひろみちゅなのは常識だけど(はてなキーワードにもそう書いてある),出てきたのははまちちゃん。そりゃあ id:orangestarひろみちゅは扱えないよな。当然はてサもなし。はてなを語る上で id:Apeman本来外せないはずだけど。我が世の春を謳歌していた fromdusktildawn が一夜にして凋落していく様は,はてな史に残るドラマだったのに。そういえば801ちゃんがガキくさいワガママ言って,はてなフェミに一発で黙らされたこともありました。

で本題は id:otsune 。今どきの人は知らないと思うけど,以前は自分ブログをやってて技術的な話題を取り扱ってた。技術レベルは正直それほど高くなかったけど,話題の拾い方が上手だったのと(これは今も健在か)自分なりに真摯に取り組んでる姿勢がよくてけっこうな人気ブログだった。それがウォチャーとしての旨味を知って手軽なことばかりやるようになって,あげく今回の騒動。

昔に帰れとは言わないが,ちょっと自分を見つめ直そうぜ。

2014-06-27

徳丸本の内容を実践しながら学べた話

新卒入社したA社は、親会社B社のシステムの内製と、B社の顧客層向けのパッケージソフトウェア制作販売するソフトウェアハウスだった。

入社1年目の自分は、いくつかの細かい業務を平行して担当することになったが、その中にホームページ管理があった。主な業務は、ページの文章更新と確認、誤字脱字の修正、古く間違ったHTML修正など。

会社ホームページには自社のサービス製品だけを扱う小さなショッピングシステムがあり、ユーザ登録・ログイン・購入・履歴確認など一通りの機能を持っていた。このシステムを改修したり更新したりする予定はなかったが、せっかく担当となったわけだし、以前から興味のあったWebアプリケーションセキュリティ勉強しようと、徳丸本を購入した。(当時は紙の本しかなかった)

http://tatsu-zine.com/books/sbcr-taiketekinimanabu

この本は説明不要の名著で、平易な文章で細かく正確な記述がなされている。Webアプリケーション制作に携わる新人プログラマは必読だ。

から読み進める。1章に用語の整理があるおかげでだいぶ理解やすい。2章の実習環境の用意は、都合がつかず読み飛ばした。3章は流し読みし、いよいよ4章。様々な脆弱性を個別にとり挙げ、原因と対策について具体的な説明がされており、非常に興味深い。

なるほど、XSSクロスサイトスクリプティング)という言葉は知っていたが、具体的にこういうものなのだな。入力ボックス入力した内容が遷移後のページに表示されるというUIはよくあるから、気をつけなければ……そういえば、会社ホームページにも検索機能があって、「検索ワード:○○」と表示されるところがあったな。あれもXSS対策がされているはずだ。どれ、見てみよう。テストサーバで画面を表示して、<script>alert(1)</script>(本当は半角)と入力……

検索ワード:
   +----------------+
   |                |
   |   1            |
   |       [  OK  ] |
   +----------------+

なるほどこれがXSSか。実習環境の用意はしなかったが、実物を拝むことができたぞ。脆弱性修正の実習もできるな。

このようにして、徳丸本を読み進め、(テストサーバで)攻撃を実践しながら、脆弱性を直していった。覚えている限りでは、以下の実習ができた:

  1. 上述のXSS。直した。
  2. SQLインジェクション - XSSと同様の検索フォーム部分、ログイン部分。誰のアカウントにでもログインできた。急いで直した。
  3. CSRFクロスサイトリクエストフォージェリ) - ログイン済みのユーザを細工されたページに誘導すると、パスワード任意の値に変更できた。すぐ直した。
  4. クッキー不適切な利用 - httponlyでないCookieに、ユーザIDパスワードナンチャッテ暗号化(全ユーザ統一の値でxorしただけ)して保存していた。1のXSSとの合わせ技でその内容を外部に送信できたし、暗号の強度もダメだったし、そもそもログイン自体に使う情報Cookieに保存すべきではない。しかしこのCookie依存している箇所がたくさんあったため、XSS修正とhttponlyの対応だけになった。一応直った。

ショッピングシステムの中身が、フレームワークライブラリなし・SQL発行共通関数なし・オブジェクト指向なし・数万行の巨大ファイル1つであることを知ったのは、脆弱性修正にとりかかってからだった。その他のシステムもすべてこのショッピングシステムを参考に作られているらしく、プレースホルダエスケープもない文字列組み立てSQL発行があらゆる場所に散乱していた。とても直し甲斐があるシステムであった。

これらのシステムは、日付zip以上のバージョン管理が行われていなかったため、該当部分を誰が書いたのかはわからなかった。そんな状況であったので、大量に報告された脆弱性始末書は、すべて現在担当である自分が書くことになった。

自分入社するより前からあった、誰が作ったのかもわからない脆弱性を、探し修正始末書を書いた。「私が担当になる前からあった脆弱性なので、原因はわかりません。おそらく不勉強が原因です。対策は、勉強会コードレビューバージョン管理です。」などと書いた。今思えば、"よい始末書"の書き方を勉強する機会を逃していたのかもしれない。

自分の作業はすべてgitで記録していたので、自分担当になったときにはすでに脆弱性があったと主張したが、「自分だけバージョン管理などという便利なものを使っていてずるい」と怒られて終わった。(なお、それよりも前に社内でのバージョン管理ツールの使用は提言していたし、それが「よくわからないから」と却下されてからは、自分だけで使う許可は得ていた。)この経験からバージョン管理をしていない、もしくはクソみたいな管理しかしていない組織内で、自分だけでも上手く管理する方法についての知見を得た。

こうして、徳丸本の内容を実践しながら学習できたので、セキュリティ分野についての興味はより高まり、知識も増え、A社に対する信頼はほとんど失われたので、さら勉強し、3年目に入るころには情報セキュリティスペシャリスト試験合格し、転職した。

Webサービスセキュリティ勉強したいと思ったならば、徳丸本を読んで、実践しながら勉強することを強く推奨する。紙の本には実験環境CDもついているので、A社でホームページ担当していなくても、実践しながら勉強することが可能だ。(電子版の場合はどうなのだろうか。申し訳ないが各自確認していただきたい。)

すばらしい本を書いてくださった徳丸先生感謝します。

http://tatsu-zine.com/books/sbcr-taiketekinimanabu

2013-09-11

市井ホワイトハッカーはどう振る舞うべきなのか

たぶんXSSが理由でインターネットがとまった

http://masatokinugawa.l0.cm/2013/09/xss.benesse.html

仕事の一環としてwebサイト脆弱性を探してる人達はたいていは所属している組織がその行為正当性保証してくれているから上記のような問題はほとんど起こりえない。問題は趣味の一環として脆弱性を探しているホワイトハッカーだ。

 

ちなみに上の記事のブクマに度々登場する「Office」とは10年前に逮捕されてしまった人のこと。

詳細は以下のページによくまとまっている。

http://www.itmedia.co.jp/news/topics/accs.html

この人が逮捕されてしまった決定的にまずかった点は、脆弱性発見過程で得られたとあるサイトに蓄積されていた個人情報を、あろうことかカンファレンスで公衆の面前に向けて公開しちゃったところ。擁護のしようがない。

 

自分ホワイトハッカーであることを証明するのは至難の業

自分では善意と思っていても、それが相手からどう見えるかどうかは別問題である客観的な証拠が無ければ善意かどうかは証明できない。それをわかっていない安易ホワイトハッカーが多すぎるように感じる。

ネット上でホワイトハッカーとして有名ならば仮に逮捕されても世論が味方してくれるなどという甘い考えも蔓延している。確かにネット世論は味方するかもしれんがそれは法廷内では何も意味をなさない。客観的状況証拠以外に善意証明する術なんて無いんですよ。だから安易ホワイトハッカー気取るのは危険なんだ。

脆弱性を見つけたらサイト管理者とIPAに迅速に報告する

これ以外にホワイトハッカーが身を守る術は無い。これを怠っておいて面倒なことに巻き込まれて「俺はインターネットを良くしようと思ってやってるのに!」とぷんすか怒っても駄目。特にIPAへの報告はできるだけ早くやる。サイト管理者よりも先に報告する。これ鉄則。

とある自称ホワイトハッカーが熱弁していた自衛手段の一つに、ブラウザのUserAgentに「僕はあなたの味方だよ!」という意味文言を入れておけば大丈夫というものがある。ジョークで言っているんだろうと思ったがどうやら本気だった模様。こういう馬鹿な人は逮捕されても仕方がない。

 

ホワイトハッカー必要なのは技術力だけじゃない。自分は無害だ、むしろサイト管理者の味方なんだという客観的事実を積み重ねる高度な政治的立ち回りが必要なんだよ。

 

確かにホワイトハッカー自体は世の中に間違いなく必要だ。でも、世間は無条件に諸手を上げてホワイトハッカーを歓迎しているわけじゃない。本当にホワイトなのかどうか見極める作業が必要なんだ。だからこそ、ホワイトハッカー側には高度な政治的立ち回りが必要となる。誰しもが客観的にその状況を見てホワイト認定してくれるようにログを積み重ねなければならない。以上。

追記

ちなみに問題となってるベネッセサイトに気になるお知らせが。これが上記の件なのかどうかはわからないが一応紹介。

http://blog.benesse.ne.jp/info/corp/2013/09/post-4.html

外部から不正アクセスを受けて内容の一部が改ざんされていたことを8月29日にお伝えいたしました。

HPを表示するためのデータの一部が、第三者によって不正に書き換えられていたことを8月29日に発見し〜

「書き換えた」とあるので、上記の人とは違うとは思うが。どうなんだろう。もし書き換えたとすればそれはホワイトどころかグレーどころかブラックなんじゃないだろうか。別件であると信じたい。

2012-09-18

malaは改良屋であってクリエイターではない

malaの代表作といえばlivedoor Readerだが、これは独創的なサービスではない。明らかにBloglinesベースにしているし、Bloglinesヘヴィユーザーだったmalaが「自分だったらこうする」という考えのもとに改良したものだ。

malaはなぜかネットで「独創的なものを作る人」というイメージを流布することに成功している。確かに彼の行動自体は独創的かもしれない。ニート時代プログラミング修行をして、そしてホリエモン逮捕と同時にライブドア入社する。そしてlivedoor Reader軌道に乗せたかと思ったら、急遽はてな転職する。はてなといえば、malaがずっと批判してきた会社だ。しかし志半ばにしてライブドアに出戻る。これらを見るだけでも、彼は十分に独創的な人生を歩んでいる。

だが彼の作っているものは独創的とは言えない。というかlivedoor Readerを作ったのは6年前だ。そしていまだにその名声で食っている。食っているというか、ネットでの評価を得ている。昔取った杵柄(きねづか)である。そして最近セキュリティXSSだのなんだのの指摘をするのをメインの活動にしている。これも、あまり独創的な仕事とは言えないだろう。他人の作ったもののあげあしを取ってるだけだ。自分が何も作れなくなったからって、なにも他人の仕事邪魔することはないだろう。いや、確かにセキュリティの指摘は重要なことだ。社会にとって必要なことだといっていいだろう。しかし、それは理屈だ。実際にはせせこましい仕事である

ところで、作っているものは独創的ではないが行動は独創的、というと誰かに似てないだろうか。そう、ホリエモンだ。彼もフジテレビを買収しようとしたり捕まったりヌードになったりモヒカンになったり出馬したりと非常に独創的な人生を歩んでいる。しかし彼の作ったものの中に一つでも独創的なものがあったであろうか。いやない。ヤフーパクリみたいなポータルサイトとか、そんなのばっかだ。つまりパブリックイメージとやってることのギャップが激しいのがライブドアマインドなのであるmalaライブドアに入る前はそんなじゃなかったはずだ。しかライブドアに入ってから変わった。事実はてなにいた頃は全く新しいサービスを作ろうと苦心していたはずだ。しかし叶わなかった。だがその心意気は認める。彼は新しいことをしようとしていた。しかしそう簡単に新しいことなどできるはずもない。運も味方しないといけない。

あの頃の情熱を取り戻すんだ。malaよ。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん