ばぁど・うぉっちんぐ

セキュリティに強いWeb屋。自由と春を求めて羽ばたく渡り鳥。

このブログはGoogle Analyticsを利用しています

同一オリジンポリシーとCross-Origin Resource Sharing

どーも。ばぁどです。 5月に備えて徳丸本を復習しています。

久々に同一オリジンポリシーに遭遇したので、個人メモとしてまとめておきます。

同一オリジンポリシー

同一オリジンポリシーとは

同一オリジンポリシーとは、同一のサーバーから取得したリソースのみJavaScript などのクライアント側で動くスクリプトからアクセスすることができるというクライアント側のWebブラウザ上で実行可能という制限です。 なぜ、このような制限があるかというと攻撃者によりhtmlファイルが書き換えられ、攻撃者が用意した悪意のあるJavaScriptをhtmlに読み込ませ攻撃される場合があるためです。

具体的にはJavaScriptから異なるオリジンに存在するリソースのPOSTメソッドを呼ぼうとしたり、異なるオリジンに存在するJavaScriptを取得して実行しようとする場合にエラーとするような挙動をします。 example.jp と example.com は違うドメインなので、example.jp のサーバーから得たJavaScriptなどのリソースが example.com に存在するサーバー対してリクエストを行うと同一オリジンポリシーでアクセスが拒否されます。

同一オリジンポリシーは、外部ファイルを読み込ませて攻撃されないためのWebブラウザ側のデフォルト設定です。

どのように同一オリジンと認識するか

  1. URLのホスト(FQDN)が一致している
  2. スキームが一致している
  3. ポート番号が一致している

上記の三つの要素が同一のものであれば、同一のオリジンとして認識がされます。 オリジンを認識するのは、ブラウザ側の設定です。

参考

developer.mozilla.org

GoogleChromeFirefox などは基本的に上記3つなのですが、IEのみポートを参照しないなど差異があります。 developer.mozilla.org

Cross-Origin Resource Sharing

Cross-Origin Resource Sharing とは

Cross-Origin Resource Sharing(CORS) とは、同一オリジンポリシーでサイト間のデータの扱いに制限がありつつも、そのサイト間データの扱いを許可するための仕組みのことです。

Webページの動的な動きは現在では欠かすことはできません。 動的な動きをWebページに加えることでUIの向上や、機能の拡充を行うことができます。 例えばGoogleMap を代表とするAjax技術です。 グルメサイトにGoogle Map が組み込まれているだけで、容易に現在位置からお店までの距離、道のりを確認しながらお店へとたどり着くことができます。

上記の例のようにJavaScriptで、動的な動きが記述されており、中には同一オリジンポリシーで制約がかけられてしまっているサイト間(サーバー間)のデータのやり取りを行いたいという需要があります。 そこで同一オリジンポリシーがありながらも、サーバー間のデータをやり取りできる仕様としてCross-Origin Resouce Sharing(CORS)が策定されました。

CORSは同一オリジンポリシーを遵守しているアプリケーションと互換を持ちながら、異なるオリジンのデータのやりとりを行うことができるようになります。

Access-Control-Allow-Origin

サーバー側の設定として Access-Controll Allow Origin という項目に許可するドメインを指定します。 HTTPレスポンスヘッダに指定することで XMLHttpRequest などのアクセス許可をすることができます。

まとめ

いったん自分向けのまとめでした。

異なるオリジンに対してのHTTPリクエストによるエラーは、社会人2年目のプログラマ時代にハマった記憶があります。 また、転職した2社目で本内容に関するレポートの作成に携わったこともあります。

【番外編】1度の就職活動、3度の転職活動を通してお断りさせていただいたヤバイと感じた企業

どーも、ばぁどです。 自称セキュリティに強いWeb屋です。

この度3度目の転職を行いました。 約2ヶ月ほどの転職活動を行い無事に内定をいただきました。

今回は1度の新卒採用時の就職活動、3度の転職活動を通して個人的に「あの企業はヤバかったな」と感じた企業を振り返ろうと思います。

※本記事はフィクションが適度に含まれております

今までの就職活動、転職活動でヤバイなと思った企業

【ヤバめ度5%】履歴書を紙で郵送してくれと言ったIT企業

2年ほど前に選考させていただいた企業様のお話です。

非常に良い印象の会社で採用技術は割と最新(Gitはもちろんのこと、CI/CDによるテストの自動化)だし、アメリカの某シリコン谷の会社とも会議をするなど英語力も活かせそうな会社でした。

ただ、如何せん古すぎました。 一次面接とても良い雰囲気で、一次面接通過の案内もいただいたのですが、 二次面接以降は履歴書を紙で郵送するということに違和感を感じてしまいました。

一次面接はエージェント経由で渡した履歴書のPDFで面接していただけたのに、二次面接は紙を郵送してもらう理由が理解できませんでした。 一次面接時に面接官が手元に持っていた履歴書は誰の履歴書ですか?

一次面接のタイミングで質問として「紙で郵送する理由」を聞いたのですが、納得できる答えをもらえず、求職者という外部との接点を持つ部分でも紙の文化が残っているということは、内部に入ったらもっと古い文化が残っておりストレスを感じるだろうと判断したため、こちらからお祈りさせていただきました。

紙の文化が残りすぎているところで業務改善は見込めないですよね。

【ヤバめ度10%】「時間を延長して欲しいですか?」という魔の言葉を囁く選考員

筆者が新卒採用の頃のお話です。 選考の過程でグループディスカッションを行っておりました。

グループディスカッションの定石として、話し合うテーマがあり、時間制限があり、時間内にまとめてグループ毎に発表していくと言った選考でした。グループは筆者のグループ含めて5グループあったと記憶しています。

グループディスカッションが時間内に終わるようにタイムテーブルを決めて、まとめに入っていましたが、選考担当者から「もうすぐ制限時間ですが、延長して欲しいグループはありますか?」と言っていただけました。

意見のまとめ、発表の仕方を討論するために時間があった方がいいと判断した筆者が所属していたグループは迷わず手をあげました。筆者のグループ以外にも2、3個のグループが手をあげたのを覚えています。

しかし講評のタイミングで「時間を延長して欲しい?と聞いた時に手をあげたグループは、社会人として時間を守れていないので失格」と言い始めました。 まぁ確かに社会人として時間を守ることは大事ですよね。その点に関しては間違いなく賛成です。 社会人であるならば、決められた時間までに出社するべきですし、締め切り期限を厳守するように仕事は進めていく必要がありますよね。時間を守ることはとても重要です。

しかし自分たちから「時間を延長してほしいグループはありますか?」と聞いておいて素直に手をあげたら、後から「時間を守れないのは社会人として失格」は少々酷くありませんか? 未だにもやもやする選考だったなと強く記憶しております。

ちなみに、その選考は企業側の不手際(選考に必要な書類が揃っておらず、選考中に印刷して学生に配っていた)により、10分ほど後ろに延長して終わりました。 「あれ?社会人として時間を守れないのは失格・・・?あれ?」

【ヤバめ度50%】なぜかキレる、質の低い圧迫面接を行う面接官

新卒で就職活動を行っていた時の企業様です。 当時の就職活動は面接などの先行活動は4月から解禁というスケジュールでした。

1月にグループディスカッションを終え「次回選考は選考解禁となる4月になるという」お話を受けて一度解散したのですが、その後「2月中に面接に進んで欲しい」という連絡が来たので、面接に進んだ時のお話です。

当時、面接を経験していなかったので練習がてら、面接に進む意を伝え意気揚々と面接会場に向かったのですが、面接中に面接担当者様がなぜか機嫌が悪かったです。

面接官:「グループディスカッションで優秀だと思った人物に声をかけたのに、この程度なんだ?」

お話を聞いてみると、1月のグループディスカッションで積極的に発言したり、リーダーシップをとっている学生を中心に4月に先んじて選考を進めてしまおうという魂胆だったそうです。グループディスカッションを経て、よりすぐった学生だったのにもかかわらず面接が思った通りの人材ではなかったらしく、意味もわからず怒られました。

いやー。。。そんなの知らんがな。

【ヤバめ度80%】自社の研修先完備のはずが、実際はSESの現場です

新卒で就職活動をしていた時のお話です。 50名ほどの企業様でSES 事業を中心に行っている企業様でした。

当時、IT系の大学に所属していながらプログラミングなどの専門的なナレッジはなく、社内研修が充実している中小企業or 大手企業を中心に選考を受けていました。

そんな時選考を受けさせていただいた企業様は「入社していただき次第、外部の研修先で学んでもらいます」ということをおっしゃっていて、研修場があるなんていい会社だと考えていました。しかし、よくよく聞いてみると、その研修先というのはSESの常駐先であり、入社1日目から自社での研修は一切なくSES先へ派遣され、技術を学んで成長して欲しいというお話でした。

学生時代であった当時SESという業態の危うさなどを理解できていませんでしたが、何か嫌な予感がしたのと当時第一志望だった企業様(新卒で4年間お世話になった企業)から内定をいただけたタイミングが重なったので、お断りさせていただきました。

これは後日談なのですが、選考途中で知り合い、同会社に入社した知人から、大学を卒業して入社する4月より前の2月や3月からSESの派遣先企業との面接のために時間を拘束されたという話も聞いており、なんか色々とアウトな匂いがする企業様でした。

【ヤバめ度100%】今御社で行っているサービスを弊社に入って立ち上げることができますか?と言ってきた企業

今回の転職活動で面接官からあった質問です。

面接官:「御社で行っているサービスを弊社に入ってから、あなた主導で立ち上げることができますか?」

え?それ逮捕されません? なんか不正競争防止法みたいなやつに引っかかりません?

選考させていただいた企業様は、受託開発及びSESを行っている企業様で、自社サービスの開発に力を入れていく方針を立てていた企業様でした。 ただ、ただ、上記質問に限らず全体的な質問の内容が変だった印象があります。

やたら筆者が所属していた企業で運営しているサービスが売れているか?を聞いてくるんですよね。 なんかしつこすぎて「少し失礼だな」とも思いました。 企業秘密に関わることであり、秘密保持契約にも抵触しそうな内容だったので適度に断りながら、のらりくらりとかわしておりました。

よくよく話を聞いてみると、 受託開発やSESでエンジニアの技術力はある程度あるので、 自社サービスを立ち上げたいが、サービスの案がないとのこと。

開発力がある企業にありがちな思考なのですが、自分たちの開発力でサービスを作れないか?という発想になったようです。 サービスって世の中の課題の解決なので、そもそも世の中を広く見渡して、どう言った課題があるか発見して、それに対する解決策をITのサービスとして提供していかなければいけないのに、そもそものサービスの考え方としてズレていたのかなと今振り返ると思います。 技術はあくまで手段であって、サービスを作る動機ではないですよね。

1番ヤバイと思うポイントが自社内でサービスの案が出てこないからと言って、 転職活動中のエンジニアがもともと運営していたサービスを、自社のサービスにできないか?と考えるのは凄い発想だなと思いました。

いや、もしかしたらそう言った意図はなく、 自発的にサービス運営に参画できるエンジニアなのかどうかを見極めたいだけの質問だったのかもしれませんが、それであるならば、サービスが儲かっているかってしつこく聞きますかね?ちょっと不快感を感じざるをえない転職面接でした。

それと、カジュアル面談は合否判定はないはずなのに、面接の最後に「合否判定は2、3営業日以内に出します」と言われました。カジュアル面談に合否があるなんて初めて知りました。世の中の広さに驚愕しました。

また、突然体調面の話になります。 体調面の話、SESを行っている企業には死活問題ですよね。 下手に体調崩して休まれると下限の時間割って計画通りの収支になりませんから。 自社サービスを引っ張ることができるエンジニアが欲しいのか、SESに出すだけの駒が欲しいのかはっきりして欲しいですね。

SES事業をやっていることと、サービスに関する考え方が合わなかったので、こちらからお断りさせていただきました。 というかカジュアル面談する前に、企業のWebページ見てSESやっていることくらい気づいておけって話ですよね。すみません。こちらの不手際でした。

まとめ

良い会社の定義って難しいですね。

エンジニアの楽園を求めて、まだまだ私は渡りを続けます。

エンジニアとして3度目の転職まとめ・転職の軸と今後の展望

はじめに

どーも、ばぁどです。 自称セキュリティに強いWeb屋です。

Webアプリケーション作成を4年ほど、サイバーセキュリティを3年ほどやっております。 この度3度目の転職を行いました。 約2ヶ月ほどの転職活動を行い、無事に内定をいただきました。

今回は雑多に3度目の転職活動をまとめていこうと思います。

転職をすると決めた理由

30代に向けての待遇と活躍の場を考えた結果です。 あまり詳しくは書きません。詳しく知りたい人はDMください。

今回の転職活動で活用させていただいたサイト

Wantedly

www.wantedly.com

今回は待遇(年収)を上げることが目的だったので、年収ではなく想いに重点を置くWantedlyは、ちょっと違いましたね。

findy

findy-code.io

3社ほどカジュアル面談と選考に進ませていただきました。 GitHubで想定収入を計測しているサービス付きの転職マッチングサービスです。

GitHub経由だったので、プログラムを書けるという前提で話を進めることができました。 選考を受けさせていただいた企業様の中には事前に筆者の当ブログ(ばぁど・うぉっちんぐ)を事前に拝見していただけていた企業様もおり、大変好感触でした。

結果今回の転職活動では、本サービスから内定に行くことはなかったですが非常に便利なサービスだったと考えております。

転職エージェント

type.jp

今回はTYPE転職エージェントサービスを利用させていただきました。 知人からエージェントを紹介していただき、大変感謝しております。

正直とても良かったです。 転職面接の日程調整などを企業様の間に入ってやっていただけますし、履歴書や職務経歴書の添削、 第一志望の企業様の面接の前には毎回電話をいただけて、選考企業様が気にしていること、どういった視点で攻めたほうがいいと言ったアドバイスをたくさんしていただけました。

次回以降転職する時も積極的に利用させていただこうと思います。

今回の転職の軸

SES事業を行っていない企業

今回の転職活動ではSES事業を行っている企業様はすべてお断りさせていただきました。

IT業界の多層請負構造に陥らせており偽装請負の温床となっているSESというサービス業態で疲弊するのはもう限界でした・・・

今回の転職活動では自ずと、自社サービスで経営できている企業様か、請負開発のみ(SESをやっていない)企業様という選択になりました。

プログラム×サイバーセキュリティ

今まで自分が磨いたスキルでプログラムとサイバーセキュリティという能力があるので、それらの能力の両方を活かせる仕事を探しました。 プログラムとサイバーセキュリティの割合はあまり拘りはなく、5:5が理想でしたが、1:9でも9:1でもよかったです。

理由としては、何かしら開発していればサイバーセキュリティは関わってくるだろうし、サイバーセキュリティやっていればプログラムの知識は腐らないだろうから、決して無理のない範囲でのわがままだったかなと思います。

転職活動の結果

無事に2社から内定をいただきました。

今回の転職活動を経て、2社の企業から内定をいただきオファーをいただけました。 このコロナ下と禍という、ご時世に選択肢を与えていただきとても幸運だなと思いました。

1社は某日系大手で本社採用、別サービス会社への出向でWebエンジニアというポジションでした。 もう1社は某日系大手企業の子会社でサイバーセキュリティに関わることができるセキュリティコンサルタントというポジションでした。

待遇面、事業規模などを考慮・悩み抜いた上で新しいスキルを吸収できるという理由から、セキュリティコンサルタントのポジションを提示していただいた企業様の内定を承諾させていただき、5月から働き始める予定です。

今後の展望

今後は遂に30代というステージに突入します。 体力的に20代と同じように深夜まで残業などの無茶な働き方や、与えられる役割、求められる職種などが変わってくる頃かなと思います。

今後の展望としては下記のスキルを身につけていきたいと考えています。

サイバーセキュリティ

次のポジションはセキュリティコンサルタントということなので、今まで以上により専門的なサイバーセキュリティの知見が求められます。

サービスを通して、サイバーセキュリティに関する知見を吸収していきます。

今の時点ではサイバーセキュリティよりWebプログラミングの方が圧倒的にスキルとしては自信がある現状なので、せめてWebプログラミングとサイバーセキュリティを五分五分の自信だと言えるようになりたいです。

目指すは二刀流の宮本武蔵です。

英語力

英語力を自信を持って仕事に使えるようにしていきたいと考えています。

時代はグローバル。 日本国内だけにとどまらず、全世界を視野に入れて仕事をしていきたいと考えています。

そのためのビジネスの場で使うための英語力。 リーディングはある程度、エンジニアとして鍛えてきたのですが問題なのはスピーキングなどの英語によるコミュニケーションです。 ここ数年、毎朝英会話を行っていますが、どうしてもビジネスで使えるという自信がないというのは個人的な悩みです。

もっと自分に自信をつけるためにも英語の自己研鑽は続けていきます。

マネジメント能力

ある程度の年齢になってくるとマネジメント層の知識が必要になってくるのは筆者も覚悟しております。

同じプログラム能力であれば、若手の方が単価は安くなりますし、Webアプリケーションのスキルは数多くのプログラムスクールから排出される人材との価格競争に陥る可能性もあります。 もちろん今後も技術研鑽を疎かにする気は全くありませんが、技術という武器だけで戦っていけるほどこの先の人生は甘くないかなと考えております。

そこで少しでも人材としてスキルを陳腐化させないためにも、今のうちからマネジメントスキルを磨いていこうと考えております。こう言ったスキルって必要になってから習得し始めるじゃ遅いんですよね。

前職でリードエンジニア的な立ち位置を経験させていただき、学生の頃のサークル活動の経験から”なんちゃって”マネジメント力は身についているのですが、体系的に組織管理、チームマネジメントを学んでいるわけではないので、それらを体系的に学んでいきたいと考えています。

幸運にも学生の頃からプロジェクトのマネジメントの経験は無駄にあるので、それらの経験を思い起こしつつ理論立てて学びへと変えていきたいと考えています。

まとめ

自分でもびっくりなのですが結構な頻度で転職をしていることに驚きです。安定志向だったはずなだけどなぁ・・・苦笑

転職活動すごい疲れるし、次お付き合いする企業様はなるべく長くお付き合いしたいと考えているのですが、こんな発言「どの履歴書ひっさげてその言葉発しているんですか?」って自分で自分に突っ込みたいです。

このご時世で、どの会社に行こうと悩める選択肢をいただけたのは幸運でした。 まだまだ長い社会人としての道のり、しっかりと自分の足で歩んで行こうと思います。

【復習・基礎知識】徳丸本で学んだOWASP ZAPでできること

どーも。ばぁどです。 セキュリティに強いWeb屋です。

諸事情ありまして、ダイエットとニートを始めました。(ニートは1ヶ月限定)。 今まではWebアプリケーション開発やプロジェクトマネジメント(なんちゃって)が中心でしたが、 5月からは脆弱性診断やら、セキュリティコンサルタントやらをやります。

5月からの仕事で必要なOWASP ZAPを徳丸本を読みながら触ってみたので自己学習メモです。 脆弱性についても復習するのでニート期間の初期は徳丸本をひたすら読み返そうと思います。

OWASP ZAP とは

OWASP ZAP(OWASP Zed Attack Proxy)とはOWASP(The Open Web Application Security Project)が開発・公開しているWebアプリケーション脆弱性診断用ツールです。無償で公開がされています。 HTTPメッセージの観察や改変を行うことができ、プロキシとしてホスト端末上で動作させることが可能です。

OWASP ZAPはJavaで記述されており、OWASP ZAPを起動するためにはJavaの実行環境が必要です。

OWASP ZAP のダウンロード

下記サイトよりダウンロードが可能です。

owasp.org

簡易的な使い方

OWASP ZAPを起動した状態でサイトにアクセスすると、HTTPでやりとりしたリクエストやレスポンスの中身を確認することができます。

f:id:UltraBirdTech:20210401182504p:plain
図0

今日学んだ OWASP ZAP でできること

1. リクエストを止めてPOST処理の値を改ざんする

プロキシなので、経由する通信を止めて値の改ざんを行うことが可能です。

プロキシを有効にするには、上部の緑色の右矢印をクリックする必要があります。

f:id:UltraBirdTech:20210401182553p:plain
図1-1

上部の緑色の右矢印が赤くなっていればリクエストを途中で止めることが可能です。

f:id:UltraBirdTech:20210401182629p:plain
図1-2

図1-2の状態で、登録ボタンをクリックするとOWASP ZAP内での表示が変わり、リクエスト途中のもののパラメーターを確認することができます。

f:id:UltraBirdTech:20210401182908p:plain
図1-3. 登録ボタンクリック前

f:id:UltraBirdTech:20210401182944p:plain
図1-4. リクエスト中パラメーター変更前

パラメーターを書き換えて、ステップを進めると遷移した先の画面で値が書き変わっていることを確認できます。

f:id:UltraBirdTech:20210401183021p:plain
図1-5. リクエスト中パラメーター変更後

f:id:UltraBirdTech:20210401183047p:plain
図1-6. 登録後(パラメーター改ざん済み)

2. Basic認証のID/パスワードのデコード

続いて、Basic認証のID/パスワードのデコードです。

以前の仕事でWireSharkなどを使用してBasic認証エンコードはやったことがあったのですが、それらをOWASP ZAP でもできるよということを改めて学びました。

f:id:UltraBirdTech:20210401183511p:plain
図2-1. Basic認証のAuthorizationヘッダー

Basic認証をするさいはAuthorizationヘッダーが付与されます。 この付与されているデータにはBasic [xxxxxxxxxxxx][]内にはIDとパスワードを:(コロン)で繋いだBase64エンコードされた文字列が入ります。

Base64エンコードはOWASP ZAP の機能で行うことができます。

[Tools]→[Encode/Decode/Hash...]

f:id:UltraBirdTech:20210401183846p:plain
図2-2. Base64のデコード

上記のようにOWASP ZAPの機能でBase64のデコードを行うことができました。

まとめ

基本的な技術の復習はとても大切ですよね。

5月に向けて頑張らねば。

情報処理安全確保支援士になって3年間、変えたことと変わったこと

どーも。ばぁどです。 もう直ぐ誕生日を迎えてラスト20代です。

情報処理安全確保支援士になって3年が経ちました。 義務付けられている3年間の講習も一回りし一通り経験してきました。

2020年の年末は情報処理安全確保支援士の更新のために必要な書類を書く年末を過ごしております。

今回は情報処理安全確保支援士となって、3年経って振り返りなどを行おうと思います。

なぜ情報処理安全確保支援士に登録したか

情報処理安全確保支援士に登録した理由は士業ってかっこいい!と思ったからです(単純

すみません。もう少し掘り下げておきます。

情報処理安全確保支援士に合格した時は社会人になって4年目の2017年でした。 その時はRuby on Rails などの フレームワークを用いて、Webアプリケーションの作成がある程度できるようになり、 一通りプログラマとしての仕事を任せてもらい、自分の技術力に自信がつき始めた頃でした。

しかしSNSにはWebアプリケーション開発の技術を極めている猛者が大勢いますし、 すぐ上の先輩にも筆者と比べて技術力がずば抜けている先輩がおり、 Webアプリケーション作成というスキルを極めていくだけでこの先の長い人生、食っていけるのだろうか?という悩みがほわわんとありました。

そんな時所属していた部門内でセキュリティ事故が起き「セキュリティを強化する」という部門方針がありました。 私はセキュリティ技術を勉強することで所属部門の方針に答えようと考え、ちょうど新設された情報処理安全確保支援士に挑戦し無事合格しました。

その後「せっかく合格したのだから、登録もしておこう」と考え、情報処理安全確保支援士に登録しました。 情報処理安全確保支援士は士業であり「情報処理安全確保支援士」として名乗れるのであれば、 Webアプリケーション開発に加えて筆者のカラーになるかなと考えておりました。

情報処理安全確保支援士になって変わったこと

情報処理安全確保支援士になっても特に何も変わりませんでした。

変わらないというのは、当然な気もしていて、筆者が在籍していた会社はWebアプリケーション開発が主体でした。 この先ずっと開発をしていても、キャリアパスプログラマシステムエンジニア→プロジェクトリーダーというキャリアパスが基本であり、 サイバーセキュリティに特化したキャリアパスがあるわけではなく、サイバーセキュリティを学べる場がありませんでした

また、情報処理安全確保支援士は士業ですが、同じ士業である弁護士などと違い独占できる商売がありません。 ほぼほぼ、情報処理安全確保支援士で独占できるのは、情報処理安全確保支援士として名乗ることができることくらいです苦笑

情報処理安全確保支援士になっても、特に変わらないということは、 この先ずっとセキュリティには関係せずに、Webアプリケーション開発のみをやっていくことになります。 Webアプリケーション開発が決してセキュリティに関係ないということはありませんが、セキュリティが主体ではいのは明白です。 セキュア開発やWebアプリケーションの脆弱性などはありますが、あくまで主体は開発でした。

筆者は情報処理安全確保支援士というのはどういったものなのかが分からず、 少なくとも情報処理安全確保支援士としてのスキルはWebアプリケーション開発の延長線上のキャリアパスではないという考えだけありました。 情報処理安全確保支援士として名乗れるものの、情報処理安全確保支援士として相応しいスキルを身につけているかの疑問を常に抱えていました。

まぁ、情報処理安全確保支援士になっただけでは「特に何も変わりませんでした」というのが私の結論です。

情報処理安全確保支援士として何を変えて、何が変わったか

上記のように情報処理安全確保支援士になっても、何も変わりませんでした。 名刺の役職欄に「情報処理安全確保支援士が」加わったくらいです苦笑

情報処理安全確保支援士になるのと、情報処理安全確保支援士として活動するのでは全然違うんですよね(当たり前

そこで筆者が行動したのは下記3つです。

サイバーセキュリティについて学べる塾に通いました

ふとしたきっかけで、ホワイトハッカーという存在を知りました。 深夜のテレビ番組で、お笑いコンビのハライチさんがMCをやっていました。 ホワイトハッカーとは、サイバーセキュリティの知識を持っており倫理観を持ち、正しいことに対して自身の技術力を提供するハッカーのことです。

自身のキャリアパスに悩んだときに、放映されたその番組はヒントを与えてくれました。

決して情報処理安全確保支援士 = ホワイトハッカーということはありませんが、 少なくともWebアプリケーション開発よりは、情報処理安全確保支援士に近づくことができると考えたのです。

Googleで調べてみた結果、都内でサイバーセキュリティを学べる塾があることがわかり、通うことを決めました。 やはりこう言ったチャンスが多いのは都内の良いところだなと思いました。

カリキュラム的にどう言ったものか、口コミがなくあまり情報はありませんでしたが、 筆者が選択したコースは月に1,0000円ほどで、自己研鑽としては許容範囲だったので物は試しに行ってきました。 カリキュラムは1年で土曜日に3時間ほどの講義がありました。 筆者はエンジニアとして4年間の経験がありますし、情報処理安全確保支援士としての知識だけは持っていたので、講義の難易度的にも問題なく、1年間受講することができました。

※なので初心者向けではないかなと個人的には思っています

私にとっては入り方の分からないサイバーセキュリティの分野への入り方としては良い選択だったなと思います。

周りの環境も変えました

仕事を変えました。 仕事は1日の大半を占める事柄です。

上述のサイバーセキュリティを学べる塾で色々とサイバーセキュリティに関する業界が見えてきており、 色々と考えて自社でサイバーセキュリティのサービスを提供している企業に転職しました。

最初はSESとして他の企業のサイバーセキュリティの案件にアサインされてひたすら案件で担当させていただいた知識を吸収しました。 後日談ですが、そのSES案件も筆者が情報処理安全確保支援士であることから最低限の知識があると評価していただけていたようです。

サイバーセキュリティの企業に所属し、普段の仕事もサイバーセキュリティになっていたので情報処理安全確保支援士としての経験を積むには文句ないキャリアを選べたかなと考えていました。

ちなみに当時の退職エントリの記事は下記です。(当時の振り返りと、今振り返りだと色々と切り口や考え方が違うものですねぇw)

ultrabirdtech.hatenablog.com

自己研鑽も欠かしませんでした

自己研鑽も欠かしませんでした。 サイバーセキュリティに関する技術本を読み漁りました。 サイバーセキュリティと関連性が深い、ネットワーク関連も勉強しました。

特にこの3年間で読んだ本の中で、下記の本がとても良かったです。

■サイバーセキュリティプログラミング――Pythonで学ぶハッカーの思考 www.oreilly.co.jp

■ハッキング・ラボのつくりかた 仮想環境におけるハッカー体験学習 www.shoeisha.co.jp

情報処理安全確保支援士として今後どうするか

先日、情報処理安全確保支援士集合研修を受けました

先日、情報処理安全確保支援士として義務付けられている、集合研修を受けてきました。(時期的に集合できないのでリモートでしたが)

集合研修で、他の情報処理安全確保支援士の方と一緒にワークを受けさせていただいて確信を持てました。

「僕のサイバーセキュリティのナレッジは他の方に劣らない物を持てている!」

これは仕事の内容をサイバーセキュリティ寄りのものに変えたというのもありますし、普段からの自己研鑽もあったかなと思います。 ワークの内容もSES先で吸収した知識を存分に発揮できたかなと思います。

これはずっとWebアプリケーション開発だけをしていたら得られなかった経験でした。

今後どうするか

情報処理安全確保支援士になりました。 情報処理安全確保支援に値するサイバーセキュリティの知見もつけることができました。(できたと思っています)

次は情報処理安全確保支援士としてどう言った行動をしていくかです。 今の仕事がサイバーセキュリティなので、そのまま続けるという選択もあると思いますし、 最近、フリーランスという道に進んでより多くの企業のセキュリティ課題について解決するような動きをしてもいいのかなとも考えてもおります。

さて、次から始まる30代というステージ。 どう言ったキャリアを歩むか自分でも考えものです。

まとめ

個人的に情報処理安全確保支援士になったことは、トータルとして良かったかなと思います。

「良かった」と思える理由は、情報処理安全確保支援士になって何かが変わったのではなく、 情報処理安全確保支援士になってから、何かを変えるように行動した結果だったかなと思います。

なんか本記事を読み返して哲学的な何かを少し感じました。「そのものがそのものである理由は何か」的なね。なんか哲学にある気がする。

さて、情報処理安全確保支援士を更新する書類を書く続きをしましょうかね。 みなさま、良いお年を。

今更ながらDrupageddonを振り返る

ばぁどです。 セキュリティに強いWeb屋です。

数年前はDrupalの開発をやっていた会社におり、現在はサイバーセキュリティの知識を蓄えてセキュリティもできるWeb屋になっています。 そんなセキュリティという観点からDrupalの記事を書こうとすると、やはり脆弱性という観点での書き口になってしまう。。。

今回は数年前に起きたDrupageddonというDrupalに存在した大きな脆弱性について書いていこうと思います。

本記事で伝えたいこと

Drupageddonって何?

Drupalの過去バージョンに存在していた脆弱性です。

2014年に「巨大隕石が地球に墜落するほど」衝撃的な脆弱性の内容であることから、アルマゲドンを文字ってつけられた脆弱性です。

DrupalのDBに対してSQLを発行する部分のアルゴリズムに欠陥があり、外部の攻撃者が望むようなクエリを発行できてしまうような脆弱性でした。

下記の徳丸先生の記事や、徳丸さんの記事の中で紹介されている海外のサイトもわかりやすく説明してくれていました。

■徳丸浩の日記 https://blog.tokumaru.org/2014/10/drupal-sql-injection-cve-2014-3704.html

■Drupageddon - SA-CORE-2014-005 - Drupal 7 SQL injection exploit demo http://www.zoubi.me/blog/drupageddon-sa-core-2014-005-drupal-7-sql-injection-exploit-demo

2017年にもDrupageddon2 という脆弱性が見つかっており、こちらも緊急度の高い脆弱性として発表されています。

https://www.drupal.org/sa-core-2018-002

drupageddon2はHTTPリクエスト部分に脆弱性が存在していたようですね。 詳しくは下記。(手前味噌で恐縮です。2年前のアドベントカレンダーの記事を発見したので苦笑) https://qiita.com/UltraBirdTech/items/4c336d34ebff0823176f#sa-core-2018-002

本家大元のアルマゲドンには続編がないにもかかわらず、Drupageddonは2までできてしまっているのが何とも言えぬ・・・

2016年に世界中を震撼させたパナマ文章も??

2016年に起きたパナマ文書を覚えていますでしょうか。 世界中の富豪達が租税回避地として使用していたパナマモサック・フォンセカという法律事務所の情報がリークされてしまった事件です。 リークされた情報は世界中のジャーナリストによって解析が進められ、疑惑が浮上した富豪達はバッシングされてしまいました。

Wikipedia https://ja.wikipedia.org/wiki/%E3%83%91%E3%83%8A%E3%83%9E%E6%96%87%E6%9B%B8

流出元になったモサックフォンセカでは、このDrupageddonを含んだ脆弱性を持つDrupalが3年にわたり脆弱性が放置されたまま運用がされていたそうです。

下記の英語サイトでも同様の記述を発見しました。 https://drupal.sh/drupal-panama-papers-leaks-mossack-fonseca.html

しかし注意点としてDrupageddonが悪用されて情報が流出したという決定的な証拠はありません。

あくまで「モサックフォンセカではDrupageddonの脆弱性を含んだDrupalを2014年の発表から3年もの間更新せずに放置していた」という事実があるだけです。

まぁ、とは言え脆弱性を放置していると、このように攻撃者に攻撃される隙を与えているのですよね。 そう言った脆弱性は確認出来次第すぐに修正していく必要があります。

要するに「脆弱性を放置すると、こういう痛い目に遭う可能性がありますよ」ということですね。

個人的な見解:Drupageddonは再び起こるのか?

絶対とは言い切れませんが、Drupageddonのようなクリティカルな脆弱性の発生頻度は落ちると考えています。

理由はDrupal7 から Drupal8 に移行する際に、内部システムがPHPのWebアプリケーションフレームワークであるSymfonyに書き換えられているからです。

少し話がそれますが、WebアプリケーションフレームワークはWebアプリケーションを開発するためのURLマッピングやDBとの接続部分の実装、ORマッパーの実装などの処理をルールとして提供してくれています。 このことによりDrupageddonのような少しお粗末なSQL発行のスクリプトは、WebアプリフレームワークであるSymfonyのルールに基本的に沿っていれば発生する可能性は低くなります。

しかしSymfonyのDB接続を担当しているORマッパー自体に深刻な脆弱性が見つかったり、もしくはDrupal内でSymfonyのルールに沿った記述ができておらず独自に作り込んでいる場合や、Drupalの拡張モジュールなどまだまだ不安になる要素はたくさんあります。

まぁ実際にDrupageddon2はDrupal8(8.5.0以前)でも発生していますしね。

このことからも決して油断することなく、常に脆弱性には気配りをしていただきたいです。

脆弱性が見つかったその時のために普段から何ができるのか?

脆弱性情報をチェックする

使用しているDrupalのバージョンや、外部モジュールを把握した上で常に下記のようなサイトをチェックしてください。 もし使用しているDrupalのバージョンや外部モジュールに脆弱性が発見された場合は、脆弱性の脅威度を確かめた上で確実に対応をしてください。

脆弱性が発表されたときに即時対応できる体制を整える

また、脆弱性が発表されたおきに即時対応することができる体制を整える必要があります。

企業ページに対して記事の更新などを行うことがCMSの強みですが、サーバー側の設定になると対応できる人が限られたり、場合によっては許可が必要な場合もあるでしょう。 そう言った、脆弱性の更新のためにどう言った手順が必要なのかを事前に確認しておき、有事の際にはしっかりと対応できるようにしておく必要があります。

要は防災訓練ですね。

まとめ

  • むかし、むかし、Drupageddonという大きな脆弱性がありました
  • 脆弱性の放置はダメ、絶対

リディクラス(馬鹿馬鹿しいコード)

ハリーポッター シリーズの中で、アズカバンの囚人がダントツで好きなばぁどです。

wizardingworld の好きなところとして、自分が知らない魔法界のワクワクが描かれているところで、次作炎のゴブレットからはVS闇の魔法使いが色濃くなるので、ファンタジー映画として楽しむ上ではアズカバンが一番好みであります。 本記事のタイトルは、アズカバンの囚人で闇の魔術に対する防衛術でリーマス・ルーピン先生が教えてくれた呪文です。

ソースコードは可読性が命です。

ソースコードは可読性が命です。 ソースコードは書く時間より、読む時間の方が多いというのはよく聞く話です。

例えば既存コードの改修であればどういった動きをするかを読む必要があります。 また数ヶ月前に書いたコードなんていうのは、コードの細部の仕様まではっきり覚えていることはありません。 仕様を覚えていなければ、再度ソースコードを読み込む必要があります。

よって、ソースコードは読みやすいことがとても大事です。

馬鹿馬鹿しいコード

エンジニアとして働いて7年。 数多くのソースコードを読んできましたが、今まで思わず画面を見ながら突っ込んでしまったソースコードにたくさん出会ってきました。 ソースコードを読んでいる時の様子を見られて、常駐先のお客様に「なんだか今日は楽しそうだね」と言われてしました(恥

そんな僕をびっくりさせてくれた、馬鹿馬鹿しいコードを紹介していこうと思います。

これはmain関数です

バカバカしいコードのお手本のようなコードでした。 そう言った教科書があれば、ぜひ掲載したい。そんな本番で動いていたコードです。

# main method
def main():
     hoge = 'hoge'

main関数という名前がついているのに、「これはmainです」という看板が建てられている。 「はっ!!!進研ゼミで見たことある!」と言わんばかりの、リーダブルコードに書かれているお手本のようなコードでした。

main関数が、main の関数であることなんて知っているわ!!!! mainじゃなければ、あなたは誰??? と、思わず画面に向かって突っ込んでしまいました。

あなた達の名前は順番に上からa, b, c, d, e

五つ子のように、上から順番にa, b, c, d, e という変数がつけられたコードを見たときは驚愕しましたね。

class Hoge():
    def __init__(self, param_list):
        a = param_list[0]
        b = param_list[1]
        c = param_list[2]
        d = param_list[3]
        e = param_list[4]

で、あなた方は何者なの? 名前が贅沢だから取られてしまったの?ここは温泉宿なの?千なの?

この変数名では生まれてしまった変数達が可哀想です。 キラキラネームであっても必ず親から子へのメッセージが託されているのに、これに関しては意味がないですからね。

変数の名前はしっかりと意味のあるものをつけてあげてください。お願いします。

君は東京-大阪間を飛行機に乗って高速道路を爆走している

Djangoソースコードを見たときの話です。

DjangoのViewのコードです。 DjangoではControllerをViewと言います。Djangoでは、MTV(Model, Template, View)です。 他のフレームワークにおける Controller です。MVCのCを担当しているのがView。 本来であればViewには、DB接続という概念はありません。 それらはModelが担当しており、ViewからはModelを介してDBにアクセスを行います。

しかし、私が出会ったコードは私の常識を遥かに超えていました。

def post(self):
    sql  = '''
           SELECT 
                   hoge_column
           FROM
                   moge_table
           WHERE
                   piyo = 
      '''
      sql += query

      result = dao.execute(sql)
      return result

Viewの中でSQLを直打ちしているだと・・・・ Modelは????? MTVモデルの意味。 しかもsqlを文字列連携している・・・

これはDjangoの使い方、Webアプリフレームワークの使い方を理解していない人のコードですね。

飛行機による移動手段は主に飛ぶことなんだよ。 飛行機にタイヤがついているからと言って、東京-大阪間を高速道路で移動しないのだ。(別にしていいけど、やらないよ)

のこぎりで釘を打ってはいけません。 道具には正しい使い道があります。

クラスの責務を否定するクラス

class ParameterClass():
     def __init__(self):
         pass

     def get_hoge(self):
         return self.hoge

     def set_hoge(self):
         self.hoge = hope

     def get_moge(self):
         return self.moge

     def set_moge(self, moge):
         self.moge = moge

class Hoge():
    def __init__(self, param):
        self.param = param

     def get_hoge(self):
         return self.param.hoge

      def set_hoge(self, hoge):
         return self.param.set_hoge(hoge)
   
class Moge():
    def __init__(self, param):
        self.param = param

     def get_moge(self):
         return self.param.moge

      def set_moge(self, moge):
         return self.param.set_moge(moge)

数年前に見たコードなので若干曖昧ですが・・・ おそらくクラス間で共有したい値を引き回すためのクラスを作ったのだろうと察しましたが、それにしてもクラスの責務を大幅に逸脱しているコードでした。

最初見たときにクラス間の責務をぶち壊すような縦串を通すようなクラスであるParamClassにびっくりした覚えがあります。

クラスにはそれぞれ責務があって・・・(疲

これらバカバカしいコードに対する防衛術

ソースコードレビュー

Git が素晴らしい。 Pull RequestやMerge Request などGit サービスによって言い方は変わりますが、それらの機能を用いてソースコードレビューをしましょう。

極稀に2人での開発だから、レビューしなくていいよねという発言が聞こえるのですが、複数人になった時点でレビューは徹底しましょう。

レビューをすることで、俗人化しやすいプログラミングという仕事を少しは緩和することができます。 他人のソースコードレビューをすることで、その人のプログラミングの癖を知り、新しいプログラミングの表現方法を発見できるかもしれません。 もちろん、ソースコード上のバグの指摘や、仕様ミスにも気づくことが可能です。

ソースコードは言葉です。ソースコードを通しての会話はプログラマ同士のコミュニケーションです。

リーダブルコード

読も! プログラマにとってのバイブルですよ!

本記事のいくつかは、リーダブルコードに書かれていることです。

www.oreilly.co.jp

まとめ

リディクラスはものまね妖怪ボガードを退治する呪文です。 しかし、この馬鹿馬鹿しいコード達は何も退治してくれません。 強いていうなら、優秀なプログラマを退治(退職)させることはできるかもしれません。

リディクラスは馬鹿馬鹿しいコードという意味で付けさせていただきました。 さぁ、馬鹿馬鹿しいコードを見つけたら唱えましょう!リディクラス!!

※リディクラスが言いたいだけの記事でした。すみません。綺麗なソースコードは大事です。