私はこうやってEGSSに潜り込んだ（中途/IT業界未経験編）

シリーズ第3弾です。3人目ともなると弊社の採用基準の多様さが徐々に見えてくるかと思います。今回の投稿もそれほど長文というわけではないので、軽い読み物としてお付き合いください。

本稿の主な目的はセキュリティ業界もしくは弊社への就職、転職をお考え中の方の参考になれば。というものですが、もちろんその他の方にもご意見ご感想いただけますと幸いです。

記事では私の経歴に触れた後、転職について、特に面接について述べています。最後に入社後の所感とちょっとした弊社のアピールを入れています。

前職まで

一般的な高校を卒業しました。特に理系にも文系にも振っていない普通の高校だったと思います。その後、物流系の会社で何年か（3～4年？）働いていました。実は前職就職時の決め手は特になく、とりあえずやりたいこともないし...といった感じで就職したものでした。ただ、仕事内容は気に入っていましたし、勤務時間や同僚などの職場環境も良かったので、割と前職も多くの方にお勧めできる仕事だったかもしれません。

転職のきっかけや面接など

そんなわけで特に転職の動機も必要性もなく何年かを過ごしていましたが、比較的時間を持て余していたので、かねてから興味があったプログラミングに手を出してみたり気になる本を読んだりしていました。その中でも、防御と攻撃の共進化の話※1に惹かれ特にセキュリティの分野に興味を持っていきました。

転職を考えだしたきっかけには何か明確なものがあったわけではありません。手を動かすうちにそれらの面白さにはまっていき、ふわっとながら徐々にこれらを仕事にしたいという気持ちが高まっていった。というような感じです。

転職を考え始めた当初は、開発系の企業でWebの技術を学ばせてもらい、そのうちセキュリティ関係の仕事を探そうと考えていました。しかし、応募するのはタダという事、何事も実務で覚えるのが最短ルートだ（技術力の高い環境であればなおよい）と当時考えていた事、等から思い直し「就職活動を始める前にメールだけでも送ってみよう」とEGSSに連絡を取りました。※2

ちなみに、EGSSに連絡したのは転職を考えた時期に特にお気に入りだった2冊の本※3の内の1冊が徳丸本だったためです。←今となっては弊社代表の本という立場ですが...

さて、ここから本稿の本題に移りますが、正直なところ採用面接において何が決め手となるかはわからないので、以下で面接について私が覚えている限りを述べます。

・面接の内容

面接は2回だったと思います。よく覚えていませんが、面談の他、確か1回目に筆記での質問、2回目に実際にPCを使っての質問を受けた気がします。筆記は徳丸本に書いてあるような内容を質問にしたもので、難易度はあまり高くなかったと思います。ここは受験者によって変わるのかもしれません。PCを使う質問でははなぜか徳丸さんが出てきて一緒に診断のさわり的な操作をやりながら質問に答えていくようなものでした。こちらもおそらく受験者によって質問を変えていると思います。間違っていたとしても考えて答えていれば多少は手を差し伸べてくれるのではないでしょうか。

・面接までにやったこと

面接に向けて特に何かをやった記憶はありません。スーツを買ったくらいです。

・面接時のセキュリティに関する理解度

セキュリティは徳丸本を読みながらであれば内容が何となく（数値化は難しいですが6割くらいでしょうか）理解できる程度であり、徳丸本含め本2～3冊程度の知識だったと思います。

ただ、それ以外の知識、例えばセキュリティに関する情報がどこから得られるのか、セキュリティ業界にどのような方（企業）がいる（ある）のか等は全然把握していませんでした。少し話題がずれますが、徳丸本を「徳丸本」と呼称していることを入社後に知って少しびっくりした記憶があります...

・その他

前述の様にプログラミングは少しかじった程度でした。入社前はかなり偏ったPCの使い方をしていたため、WordやExcel、コピペのショートカットなどの基本的なPC操作も入社後に覚えたものが多いです。また、英語力については、面接時には全く話題に上がらなかったものの、実務では英語資料に触れることがあります。私の英語は今も中高生レベルで日々Google翻訳に頼りながら仕事していますが、もし堪能であればアピールポイントになるかもしれません。

入社後

前回、前々回のエントリのお二人同様、私も入社後は様々な業務に携わりました。また、特に技術面では個人で勉強していた時とは比較できないほど多くのことを学べていると思います。

入社前とのギャップとしては資料作成の時間が多いことでしょうか。業務時間内の割と多くの時間を日本語表現をどうするかに使っている気がします。この辺りは入社面接時にも念押しされるはずです。

最後に、本稿の趣旨から外れますが、就職、転職をお考えの方に私なりの弊社のおすすめポイントを簡単に紹介します。

まず挙げられるものとして技術力があると考えています。実際のところ、かつて弊社に在籍されていた方や他所から転職されてきた方を見る限り技術力に秀でたセキュリティベンダーは他にもありますし、おそらく私がまだ知らない方々や企業も多いはずです。ただ、弊社は徳丸本著者の会社ですので入社前からある程度の期待を持っていただいてよいと思います。（もちろん、徳丸さん以外にも実績があるメンバーがいます。）

また、小さい会社なので自由度が高いです。作業内容、事業内容ともにやりたいといえば比較的なんでもやらせてもらえる環境だと感じています。他にも徳丸さん含め社員のメンバーとの距離が近いことや検証用環境が用意されていることなんかもお気に入りのポイントです。

[PR]EGセキュアソリューションズ株式会社はエンジニアを募集しています

社内の環境などについて、○○はどうなっていますか？等のご質問がある場合はコメントをお願いします。答えられる範囲であれば次回以降の方が回答いたします。

最後まで読んでいただきありがとうございます。

シリーズ第4弾にご期待ください。

※1「Hacking: 美しき策謀 第2版 ―脆弱性攻撃の理論と実際」です。内容は少し古いです...

※2 スケジュールの都合上、実際には別の企業も同時に面接を進めることとなりましたが。

※3 もう一冊は「暗号技術入門 第3版」でした。徳丸本が好きな方であればこちらも面白いと思います。

私はこうやってEGSSに潜り込んだ 他業種中途編

こんにちは、EGセキュアソリューションズ(EGSS)の黒木です。

前回に引き続き「こうやってEGSSに潜り込んだシリーズ」として他業種から中途入社した私(黒木)の事例を紹介します。

他業種から来た中途の人ってどういう人なの？というのを知っていただければと思います。

なお、技術的なお話は一切出てきません。

 

 

いままでのキャリア

EGSSは私にとって3社目の会社になります。

 

1社目では、主にISP事業者のお客様拠点で、サーバの運用保守業務に3年近く従事しました。

24時間365日の交代勤務でシステムに異常がないかチェックし、何かあればサーバにログインして障害対応をしたり、場合によってはデータセンターまでタクシーで駆けつけたりもする仕事でした。

千台を優に超えるサーバがあり、毎日どこかのサーバが壊れていたため非常にやりがいがあったように思います。

余談ですが、この現場では「今日は平和ですね」は帰れなくなるので禁句でした。

 

 

2社目は、主に航空会社のお客様拠点で、EOLシステムの更改プロジェクトや、アプリケーションの配布プロジェクトなどで、サーバ系のプロジェクトを推進していく立場として(最初は見習いからですが、)約3年従事しました。

当初は「バージョンをちょっと上げたり、ぱっとソフトを配るだけでは？」と思った時期もあったような気がしますが、当然ながら実際全くそんな事はありませんでした。

考慮しないとならない人的、システム的もしくは技術的条件、万一の時の影響の大きさ等、難度があがる要素が色々あったように思います。

 

 

そして3社目が弊社EGSSなのですが、上記の通りセキュリティそのものを業務上で担当していた時期はありませんでした。

ではなぜ、私はセキュリティ会社であるEGSSに転職したのでしょうか？

 

 

セキュリティとの関わり

セキュリティを業務上担当することはなくとも、システム開発、運用でセキュリティに一切関わらないということは無いと思います。

私の場合、2社目でシステム開発に携わった際によく考えることになりました。

 

どういったセキュリティ施策があるのか、このシステムに適用できる施策はどれか、どこまでするのが妥当なのか、そもそも有効な施策なのだろうか。等。。

 

システムそのものと違い、セキュリティ対策は無くともシステムを稼働できてしまうので、なおのこと心配になりました。

何かあってからでは、お客様企業やその先の利用者にご迷惑かかってからでは遅いからです。でも無限に時間もお金もかけられません。

 

とはいえ、実のところこれは開発者にとっても管理する側(企業)にとってもよくある心配事ではあるので、開発指針やガイドラインといったもので必要な情報は入手することが容易にできる環境でした。

しかしガイドラインに沿って開発すれば万事解決かというと、必ずしもそうではありません。

適切な知識がなければガイドラインの意図を読み違える可能性がありますし、せっかくのガイドラインを形骸化させてしまう心配もあるからです。

 

 

色々と悩んだ末、確かな考え方や知識を得るためにも私は学生に戻ることにしました。

 

 

学生生活とEGSSへの参画

 

学生に戻ると決めたものの生活はしていかないといけませんので、仕事をしつつ通える東京都立産業技術大学院大学(AIIT)に通うことにしました。

このAIITでシステム開発やセキュリティの勉強をし直すにあたり、手に取った本の1つがいわゆる徳丸本でした。

...はい、私(当時27歳)はここまで徳丸本を知りませんでした。

それまでウェブ周りにあまり関わってこなかった事が大きいと思いたいですが、私が不勉強なだけかもしれません。

 

ともかく読んでみると、なるほどこうやって上手くセキュリティ上の安全を確保しているのだなと思う反面、正しく知っていないと簡単に穴を開けてしまいかねないと理解できました。

また、とある脆弱性学習用のアプリケーションの中で初めてBlindSQLインジェクションを用いて不正ログインが出来た時の心境は、なんとも不思議なものでした。

悪戦苦闘してようやく上手くできたという達成感とは別に、悪用すればこのようにログインできてしまうのかと戦慄した覚えがあります。

これはセキュリティの大切さを「知っている」だけでなく「実感」した瞬間だったような気もします。

 

こうした取り組みを進めるなかで、やはりシステム開発者やサービス提供者はセキュリティはしっかりと理解していないとならないと再認識しました。

そして、セキュリティという分野が面白い領域だと感じ、出遅れを感じつつもセキュリティ業界に潜り込もうと決意しました。

 

そして潜り込み先は、そう思うきっかけとなった徳丸本の中の人の会社...EGSSでした。

EGSSへの応募にあたっては、社長がウェブセキュリティ界隈で有名な人であるし、時折SNS等に鋭いコメントをしているのも見ていましたので、きっと面接で詰められるんじゃなかろうか、そもそも書類審査通らないんじゃなかろうかと胃が痛くなる思いでした。

しかし実際はそんなことはなく、社長直々の実技試験も終始和やかな雰囲気で行われ、無事採用となりました。

私に「EGSSが求人しているからダメもとで受けてみれば？」と、背中を押していただいた研究室の同期に大変感謝しています。

 

 

 

まとめ

他業種からセキュリティ業界に参画するまでの経緯をご紹介しました。

もしかすると、セキュリティ業界に辿り着くまで少々遠回りしたように思われるかもしれません。

しかし、私は今思うとそんなこともないかなと考えています。

 

システム開発における知見、考え方、システムの難しさや、うっかり陥りがちな事など、これらは中々話して伝わるものでは無いと思います。

これらを実感として理解していることは、脆弱性診断やセキュリティコンサルティングを行うにあたり大切なポイントであると考えています。

 

なぜなら、セキュリティを仕事にする者として大切なことの1つとして、「現実的な危険を知らせ、開発者や経営者に正しく理解していただくことで、インターネット環境の安全性向上に寄与し、少しでも被害に遭う利用者を減らす。」というのがあると私は想っており、これらの達成には今までの経験が非常に有益だからです。

 

 

という訳ですので、

「他業種だけれどセキュリティを仕事にしたいと思っている、けれど経験が無いから躊躇している。」

と思っている方もセキュリティ業界でご活躍できる場面は多いと思います。

他業種のご経験はきっと活きると思いますので、是非一歩踏み出してみていただければと思います。

また、その際にはEGSSも選択肢に加えていただけると幸いです。

私はこうやってEGSSに潜り込んだ 新卒編

こんにちは。エンジニアの竹添です。
本日は、新卒でセキュリティエンジニアになった私が、どのような経緯で業界に足を踏み入れ、どのようなお仕事をしているのか、というテーマで記事を書いてみたいと思います。

セキュリティエンジニアの業界に興味を持っている方に、今後の参考として読んでいただければ幸いです。

自己紹介

はじめに、私のプロフィールを公開します。
・年齢：25歳（1994年生まれ）
・出身：長崎県
・趣味：アニメ、バイク、お料理
・技術領域：ウェブセキュリティ全般、PHP、WordPress

我ながら、これといった特徴も無い普通のプロフィールだと思います。
技術領域に書いてある内容も、ここ2,3年で身に付けたものです。
大した事無いじゃないか、と思っていただくために書きました。

わたしの学生時代

大学は理系の情報工学部に所属していました。
絵に描いたようなインドア学生生活をしていたので、惰性で毎日を送っていました。
大学で出された課題をこなして後は好きなことをするだけの生活です。

そんなある日、知人の紹介でセキュリティ系の勉強会に足を運ぶ機会があり、
これをきっかけにセキュリティの分野に興味を持つようになりました。

あまり耳にしたことのない話が多くて、注目されている。
目新しい感じがして、難しそうなことをしていて、かっこいい。
雑ですが、最初に感じたイメージはこの通りでした。

その後、無知な状態からのスタートでしたが、
情報をキャッチアップする手段を覚え、
業界で起こっている出来事や考え方に触れる機会が増えたことで、
徐々に面白さが分かるようになっていきました。

卒業後の話

大学を卒業してからは、セキュリティエンジニアになりたいと思うようになりました。
理由はたくさんありますが、少し背伸びをするレベルのお仕事をやりたかったこと、とても多くの事を学ぶことが出来そうなこと、これまで会ってきたセキュリティエンジニアの方々が楽しそうにお仕事の話をしていたことが主な動機でした。

「新卒からセキュリティエンジニアを職にするのは難しいから、まずは開発や運用を学んでからにした方がいい」
というアドバイスを受けることもしばしばありましたが、諦めの悪い性分だったので就活の方向性をそのままセキュリティエンジニアに絞りました。

アルバイトを開始

まず、自分の実力が不足していることを知っていた私は、
セキュリティエンジニアになるために必要なスキルを身に付けたいと考えました。
そこで、知人のWeb系の会社に頼み込み、アルバイトとして雇って貰いました。
全くの未経験からのスタートでしたが、最終的にPHPとWordPressの話を多少出来るレベルになりました。

後から振り返ってみると、
この時勇気を出して開発経験を身に付けて良かったと思います。
作り手としての考え方はセキュリティを考える上で強い武器になるからです。

脆弱性診断を例に挙げると、
自分が送信した攻撃文字列が、システムに受け取られた後、
どのように処理されるか仮説を立てながら攻撃を行うことが出来るため、
精度面や効率面で大きなメリットを感じました。

採用に至るまで

Web業界への名残はありましたが、
1年のアルバイト期間を経て、私はEGセキュアソリューションズの門戸を叩きました。

EGセキュアソリューションズは、かの徳丸本の著者である徳丸さんの会社で、少数精鋭のため新卒を募集しておらず、狭き門だという事を理解していました。
ですが、他社と比べた時に、セキュリティベンダーとしての「建前」が無く、本気でお客様のセキュリティ向上に取り組んでいるように見えたので応募に踏み切りました。
※これから弊社に応募される方は、志望動機欄に同じ事を書かないようにお願いします。

実際の採用面接についてはあまり記憶が残っていませんが、志望動機等のヒアリングに加え、「ウェブの世界を安全にしたい」という社の方針に対する自分の考えを問われました。
また、二次試験では実技試験として、徳丸さんと一緒に脆弱性診断を行いながら見つけた事象に関する質問を受けますが、私はことごとく間違えました。

結果としては内定をいただくことが出来ましたが、
今になって思うと、Webの開発経験と、業界の情報を多少なりともキャッチアップしていたことが評価されたおかげではないかと思います。

入社後の話

セキュリティエンジニアといっても様々なお仕事がありますが、
EGセキュアソリューションズでは、社員の基本スキルとしてWebアプリケーションの脆弱性診断を学びます。
新入社員はまず、社長の著書『徳丸本』を片手に脆弱性の原理と影響を学び、研修用のやられサイトの脆弱性診断を行います。
結果は報告書にまとめ、社長から直接レビューを受けることになります。

やられサイトは名前の通り、「やられること」を目的としたサイトのため、たくさんのバグや不具合が見つかります。それらの中から脆弱性として問題のある事象を報告するのはとても大変で、確認漏れがあったり、分析が甘かったり、間違った解釈をしてしまったりと苦労することが多かったです。

また、脆弱性診断で技術力を磨く一方で、
お客様とのやり取りにも積極的に参加し、たくさんの事を学びます。

メールや打ち合わせでのやり取りで、お客様が求めている事をヒアリングし、
弊社が出来る事を理解していただくのは口にするほど簡単ではありません。
「メールでどのような書き方をすればこちらの意図が伝わるだろうか…」
「お客様が本当に求めている事はどのように聞けば良いだろうか…」
日々こんなことばかり考えていますし、それが楽しいです。

担当した業務

業務は脆弱性診断とお客様連絡を中心にしつつ、

希望業務にはどんどん関わる社風のため、色々なお仕事に参加させて貰いました。

私は元々計画を立てることが好きだったこともあり、イベントの運営担当も務めました。

• Web、プラットフォーム脆弱性診断
• 開発ガイドラインの策定
• お客様連絡
• イベント運営　etc...

入社後に思った事

セキュリティには技術的な要素だけでなく、コミュニケーションによる状況把握能力や解決策を考える思考能力も必要で、総合力が要求されることが分かりました。

また、入社前に抱いていたイメージよりも地味で根気のいる作業が多く、地道に経験を積みながら業務に慣れることが出来ました。私は元々地道な作業を好んでいたこともあり、このお仕事に対する適正が高かったのかもしれません。

加えて、ビジネスにも共通する話だと思いますが、普段から心掛けていることが業務に役立つことも多々ありました。情報のキャッチアップ然りすぐ手を動かすこと然り。自分が必要と思う事は積極的に挑戦するべきだと思いました。

まとめ

本日のまとめです。

• まずは行動を起こすことが大切
• セキュリティエンジニアは技術力だけでなく、総合力が求められるお仕事

皆さんの中には、セキュリティエンジニアは華やかなお仕事というイメージを持っている方がいるかもしれません。
それは高難度の案件をずば抜けた技術力のエンジニアが解決するイメージが強いからだと思います。
ですが、私のような人間がセキュリティエンジニアとして生計を立てることが出来ているのも事実です。


セキュリティはこれからもっと一般的な業界になります。
この記事を通して皆さんも業界に興味を持っていただけると幸いです。


PR
EGセキュアソリューションズ株式会社では、私たちと一緒に働く仲間（脆弱性診断員、コンサルタント）を募集しています。新卒・既卒問いませんので、興味のある方は採用ページを参照下さい。

Apacheが最新版(2.4.41)かどうかを確認する方法

こんにちは。EGセキュアソリューションズの社長の徳丸です。
今日は、Apacheが本稿執筆時点での最新版 2.4.41 であるかを確認する方法を公開しちゃいます。

はじめに

脆弱性診断の一環で、サーバーソフトウェアのバージョンを確認したいというニーズがあります。今どき、Apache等のServerヘッダにバージョンが出ていることはまずない（…とも言えず実はよくある）ので、Serverヘッダ以外からソフトウェアのバージョンを確認する方法が知られています。以下はその例です。

• Apache HTTP Serverのバージョンを当てる方法
• 僕が調べたApacheバージョン判定の小ネタ
• 診断文字列を打ち込まずにPHPのバージョンを推測する

2番目の、とある診断員さんの記事は、Apache 2.2のすべてのバージョンをビルドして確認する方法が具体的に説明されています。そして、上の２つの記事はApache 2.2を題材にしていますが、2.2はとっくにサポートが終了しており、2.4系のバージョン確認の方法が求められますよね。
実は、Apacheの最新版 2.4.41 になって、エラーメッセージの表示内容が微妙に変わりましたので、バージョン確認に使えます。まずは、404 Not Foundの表示を用いて説明します。

試してみよう

以下は、Apache 2.4.39（2.4.40は欠番）における存在しないパス /xx に対するレスポンスの例です。

HTTP/1.1 404 Not Found
Date: Thu, 30 Jan 2020 01:48:04 GMT
Server: Apache/2.4.39 (Unix) PHP/5.3.3
Content-Length: 200
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /xx was not found on this server.</p>
</body></html>

以下は、Apache 2.4.41（最新版）における /xx に対するレスポンスの例です。

HTTP/1.1 404 Not Found
Date: Thu, 30 Jan 2020 01:50:08 GMT
Server: Apache/2.4.41 (Unix) PHP/5.3.3
Content-Length: 196
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL was not found on this server.</p>
</body></html>

2.4.39までと比べると、パス名(/xx)が省略されていることがわかります。これを使ってApache 2.4.41か、それより前のバージョンであるか判別できます。

404ページをカスタマイズしている場合

ただ、404 Not foundのページは通常カスタマイズされているのでApacheが生成するレスポンスボディを見ることはできないケースが多いと思います。その場合は、他のステータスを用いることができます。たとえば、TRACEメソッドは禁止されているケースが多いと思いますが、この禁止されている場合のレスポンスが使える場合があります。

まずは 2.4.39の場合（リクエストとレスポンス）

TRACE /xx HTTP/1.1
Host: apacheall:2439

HTTP/1.1 405 Method Not Allowed
Date: Thu, 30 Jan 2020 01:59:48 GMT
Server: Apache/2.4.39 (Unix) PHP/5.3.3
Allow: 
Content-Length: 225
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>405 Method Not Allowed</title>
</head><body>
<h1>Method Not Allowed</h1>
<p>The requested method TRACE is not allowed for the URL /xx.</p>
</body></html>

次に、2.4.41の場合（リクエストとレスポンス）

TRACE /xx HTTP/1.1
Host: apacheall:2441

HTTP/1.1 405 Method Not Allowed
Date: Thu, 30 Jan 2020 02:03:11 GMT
Server: Apache/2.4.41 (Unix) PHP/5.3.3
Allow: 
Content-Length: 222
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>405 Method Not Allowed</title>
</head><body>
<h1>Method Not Allowed</h1>
<p>The requested method TRACE is not allowed for this URL.</p>
</body></html>

やはり、2.4.39まであったパス名が2.4.41では省略されています。脆弱性診断実務では、TRACEメソッドの許可を調べているケースが多い（参照）と思うので、一石二鳥ですよね!
ステータスの405までカスタムエラーページを用意してあればこの方法でもダメですけどね。Apacheのソースコード（./modules/http/http_protocol.c）の差分で見る限り、以下のメソッドがチェックに使えそうです。

Code	Reason-Phrase
305	Use Proxy
403	Forbidden
404	Not Found
405	Method Not Allowed
406	Not Acceptable
410	Gone
412	Precondition Failed
413	Request Entity Too Large
451	Unavailable For Legal Reasons
501	Not Implemented
506	Variant Also Negotiates

これらのステータスには、引き起こすのが難しいケースもありますが、403, 404, 405,  501あたりが使いやすそうです。

ただし、404を観察するくらいならともかく、エラーを故意に起こす通信は不正アクセスの予備行為と見なされ得るものですので、許可を得ていないサーバーで勝手に試すことは慎みましょう。

どうやって調べたか

Apache の2.2、2.4のすべてのバージョンをビルドして、それぞれポート番号を変えて実行する環境を作りました。先のリクエストで、apacheall:2441 というHost名が見えていましたか、ポート番号 2441 = Apache 2.4.41 という意味です。最終的にソースコードを確認する場合でも、動的解析であたりをつけておくと作業が楽ですよね。

まとめ

Apache 2.4.41以降か、それ未満かをチェックする方法について説明しました。まだApache のバージョンを2.4.41にしているサイトはそこまで多くないと思いますので、脆弱性診断等で「Apacheが最新版ですないです!! ドヤー」とすることができます…
というのは冗談で、この程度でドヤ顔はよくないですw ApacheはLinuxディストリビューションのパッケージで導入していて見かけのバージョンは古いがパッチが適用されているケースが多いですからね。現実的なリスクを踏まえて適切なアドバイスを心がけましょう。

PR

EGセキュアソリューションズ株式会社では、徳丸とともに働く仲間（脆弱性診断員、コンサルタント）を募集しています。興味のある方は採用ページを参照下さい。

【サービスのご紹介】徳丸本講座

こんにちは。EGセキュアソリューションズ セミナー運営事務局です。

本日は、6月3日(月)・4(火)に実施する『徳丸本講座』について、

受講いただくメリットや各講座の内容について簡単にご紹介します。

はじめに、『徳丸本講座』の概要について弊社ホームページでは以下の通り紹介をしております。

『体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践　第2版』（通称：徳丸本第2版）の内容を著者とともに学ぶ講座です。
本講座は、Webアプリケーションの脆弱性について座学形式での解説を行うものです。基礎講座では徳丸本第2版の中から最低限押さえておくべき内容を、応用講座では徳丸本第2版の中でも特に理解の難しい内容を学びます。

『徳丸本講座』では、皆様がWebアプリケーションの脆弱性（以下、脆弱性）に対する理解を深め、日常業務に役立てていただくことを第一の目的としています。そのため、脆弱性を突いた攻撃のデモを交えて、脆弱性の原理・影響・対策をお伝えします。脆弱性の特性について理解することで、脆弱性を作り込まないための考え方を養い、脆弱性が発見された場合の適切な対処を取ることを助けます。

続いて、それぞれの講座についてご紹介します。

基礎講座

　Webアプリケーションの脆弱性の中でも広く知られているもの・影響度の高いものを取り扱います。普段Webアプリケーションの開発を行っている方からWebサイトの開発を依頼する立場の方まで広くご参加いただきたい内容となっています。

本講座で取り扱う主な内容

• HTTP通信の概要
• クッキーとセッション管理
• クロスサイト・スクリプティング（XSS）
• SQL呼び出しに伴う脆弱性
• クロスサイト・リクエストフォージェリ（CSRF）　etc...

本講座の対象者

• PHPやJavaScriptの初歩的な知識をお持ちの方
• WebアプリケーションがWebサーバから受信した情報をブラウザで表示していることを理解出来る方
• 脆弱性について一通り理解があるものの原理から学び直したいとお考えの方

応用講座

　Web APIやJavaScript、キャッシュ機能を利用する際の脆弱性等少し難易度の高い脆弱性を取り扱います。こちらには、OWASP Top10 2017にランクインしたXXEや安全でないデシリアライゼーション等が含まれます。

　開発スキルが向上すると、自由度の高い機能を使いこなす機会が増えてきますが、それと同時に取扱いにも注意が必要となります。応用講座は、開発技術やセキュリティ技術の向上を目指す方に是非受講していただきたい内容となっております。

本講座で取り扱う主な内容

• 同一オリジンポリシー
• CORS
• Web API実装における脆弱性
• 構造化データの読み込みにまつわる問題　etc...

本講座の対象者

• PHPやJavaScriptの基礎的な知識をお持ちの方
• Web APIとJSONの概要をご存知の方
• 複数のページ間で行われる通信を想定できる方

最後に

　徳丸本講座は、Webアプリケーションの脆弱性についての理解を深めるには最適な講座です。詳細やお申込み方法については次のURLをご参照ください。

【2019年7月25日　追記】最新の講座詳細URLに更新しました。

URL：https://www.eg-secure.co.jp/registration_for_security_lecture_4/

【連載】JSONとJSONPの違い、そしてそれにまつわる脆弱性

こんにちは。EGセキュアソリューションズ診断チームです。

JSONとJSONPという、Webサイトを構築する上でよく目にする技術について、
使用する上で注意すべき脆弱性を、解説を交えながら紹介したいと思います。

連載第一回の今回は、前段の知識としてJSONとJSONPの概要について説明します

【JSONとは？】

JSONはXMLに代わるデータ交換形式として新たに提唱されたものです。
JavaScriptのオブジェクトリテラルの形式をベースとして作られています。
また、JSONはJavaScriptの式として解釈できる性質を持ちます。

JSONは名前と値がペアになっているデータの集合体として表されます。
名前と値を「：」(コロン)でペアとして記述し、データの間は「,」(カンマ)で区切ります。
これらを{}で囲んだものがJSON形式となります。実際のデータ例を下記に記します。

{ “title” : “Hello JSON!” , “No” : 123 }

【JSONPとは？】

JSONPとはJSON with Paddingの略です。
名前にJSONと含まれているため、同じようなものと思ってしまいがちですが、全く違うものです。

元々、データを異なるオリジン間でやり取りを行うために色々な手法が試されていましたが、
そのうちの一つがJSONPです。

JSONのやり取りにはXMLHttpRequestが使用されていますが、
XMLHttpRequestは元々同一オリジンポリシーの制約を受けていた（現在はCORSにより回避可能）ため、
そのままでは異なるオリジン間でデータを受け渡すことができません。
そのため、XMLHttpRequestを使用せず、script要素を使用して外部のJavaScriptを直接実行することにより、
異なるオリジン間でデータをやり取りするという方法が考案されました。これがJSONPです。

ただし、やり取りするデータがJSONの場合、JSON文字列そのままでは
script要素でデータを受け取ることができないため、関数呼び出しの形でデータを生成します。

【JSONとJSONPの違い】

ここまで簡単にJSONとJSONPの概要を述べましたが、一言で書くと次のように表すことができます。

JSON　：データ交換用の形式、またはデータそのもの

JSONP ：データそのものを異なるオリジン間でやり取りするための手法

【次回予定】

第二回以降は、いくつかあるJSONとJSONPにまつわる脆弱性について、一つ一つ紹介していきたいと思います。

WordPressサイト移行に便利なDB置換ツールを使う際の注意点

WordPressサイトの引っ越しや、開発環境から本番環境への移行等によりドメイン名やディレクトリ構造を変更する必要がある場合、データベース内のドメインやURLをSQLで直接書き換えるのではなく、DB置換ツール（Search Replace DB）が広く利用されているようです。

WordPress の引越し（WordPress Codex 日本語版）
http://wpdocs.osdn.jp/WordPress_%E3%81%AE%E5%BC%95%E8%B6%8A%E3%81%97

Search Replace DB
https://interconnectit.com/products/search-and-replace-for-wordpress-databases/


Search Replace DBはとても便利なツールですが、データベースのユーザ名/パスワードを
入力することなくデータベースを書き換えることができるため、利用する際には、セキュリティを十分考慮してください。
利用の仕方によっては、サイト上のコンテンツが改ざんされるだけでなく、以下のような被害を受ける危険性があり、現在、放置されたSearch Replace DBを利用した攻撃が観測されています。


■想定される被害の例

• データベースのアクセス情報（データベース名、ユーザ名、パスワード、
  ホスト、ポート）が漏洩し、データベース内のデータが漏洩する。

• データベース内のデータにPHPコードを混入されることで、
  仮想通貨のマイニング、OSの不正操作等、任意のコードが実行される。

以下のチェックポイントにチェックがつく場合、至急いずれかの対策を実施いただくことを推奨します。

■チェックポイント

• 作業が終わったにも関わらず、Search Replace DBを削除していない。
  （Ver.3の場合は「delete」ボタンをクリック）
• Search Replace DBへのアクセス制限を実施していない。
• Search Replace DBをWordPressのルートディレクトリ等わかりやすい場所に配置している。

■対策

• Search Replace DBを削除する（推奨）
• Search Replace DBを削除できない場合はアクセス制限を実施する

Search Replace DBのサイトには、インストール時の注意事項の記載があります。このようなツールやスクリプトを利用する際は、注意事項を正しく理解してから利用することが大切です。
また、利用完了後はただちに削除し、利用中も外部からアクセスできないように、アクセス制御することが鉄則です。


【参考】
WordPressのプラグインDuplicator 1.2.40以前にリモートコード実行の脆弱性（徳丸浩の日記）
https://blog.tokumaru.org/2018/09/wordpress-duplicator-plugin-vulnerabilty.html