ばぁど・うぉっちんぐ

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

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

OSINTツール theHarvester を使ってみたのでまとめ

どーも。ばぁどです。

theHarvester とは

Pythonで書かれてたOSINTツールです。 Web上に公開されているメールアドレスやドメインなどの情報を収集することが可能です。

github.com

Google はもちろんのこと、bingやyahooなどの検索サイトで公開されているかどうかを確認することが可能です。

実際に使ってみる

GitHub から clone する

$ git clone https://github.com/laramies/theHarvester.git
Cloning into 'theHarvester'...
remote: Enumerating objects: 6571, done.
remote: Total 6571 (delta 0), reused 0 (delta 0), pack-reused 6571
Receiving objects: 100% (6571/6571), 4.66 MiB | 3.22 MiB/s, done.
Resolving deltas: 100% (4404/4404), done.

初期設定

requirements.txtが存在するので、pip installで必要なライブラリなどを取得する。

$python3 -m pip install -r requirements.txt

※必要に応じて sudo 権限を用いる

実行

実行コマンド

python3 theHarvester.py -d [domain] -l 100 -b all

実行結果

※ドメインやIPアドレスはマスキングしています。

*******************************************************************
*  _   _                                            _             *
* | |_| |__   ___    /\  /\__ _ _ ____   _____  ___| |_ ___ _ __  *
* | __|  _ \ / _ \  / /_/ / _` | '__\ \ / / _ \/ __| __/ _ \ '__| *
* | |_| | | |  __/ / __  / (_| | |   \ V /  __/\__ \ ||  __/ |    *
*  \__|_| |_|\___| \/ /_/ \__,_|_|    \_/ \___||___/\__\___|_|    *
*                                                                 *
* theHarvester 3.2.0dev0                                          *
* Coded by Christian Martorella                                   *
* Edge-Security Research                                          *
* cmartorella@edge-security.com                                   *
*                                                                 *
******************************************************************* 


[*] Target: [domain] 
 

[!] Missing API key. 

[!] Missing API key. 

[!] Missing API key. 

[!] Missing API key. 
Searching results
[*] Searching Duckduckgo. 
[*] Searching Baidu. 
    Searching results.
[*] Searching Suip this module can take 10+ min but is worth it. 
[*] Searching Dnsdumpster. 
[*] Searching Otx. 
[*] Searching Exalead. 
    Searching results.
[*] Searching Bufferoverun. 
[*] Searching Dogpile. 
    Searching 0 results.
[*] Searching Threatcrowd. 
[*] Searching CRTsh. 
    Searching results.
    Searching 0 results.
[*] Searching Bing. 
[*] Searching Virustotal. 
[*] Searching Netcraft. 
    Searching 100 results.
[*] Searching Google. 
    Searching results.
[*] Searching Certspotter. 
    Searching 100 results.
[*] Searching Linkedin. 

[*] Users found: 13
---------------------
Christine Flynn - QESH Document Controller - [domain]
Cynthia Rubio - Executive Secretary - [domain]
David Yu - Rolling stock engineer - [domain]
Deepak Dubey - Senior Manager - [domain]
Dr. SOTIRIOS PASCHALIDIS - Director - [domain] Ltd
Duncan White - Resident Engineer Roads - [domain]
Edom Bezu - Topographic Engineer - [domain]
[domain] [domain] - Truck Driver - Transputinas ltd
Maurice Opar - Assistant Engineer - [domain]
Phillip MBULIGWE - Environmental Expert - [domain]
Pragati Srivastava - Manager HR - [domain] India
Rajkumar Vishwakarma - Engineer - [domain]
Shivani Sonu - Assistant Manager - [domain] India Pvt Ltd.
    Searching 100 results.
[*] Searching Linkedin. 

[*] No links found.


[*] Searching Intelx. 

    Searching 0 results.
[*] Searching Trello. 

[*] IPs found: 5
-------------------
24.xxx.xx.xxx
158.xxx.xxx.xx
183.xx.xxx.xx
183.xx.xxx.xx
210.xxx.xx.xxx

[*] Emails found: 1
----------------------
contact@[domain]

[*] Hosts found: 19
---------------------
an[domain]:183.xx.xxx.xx
blog.an[domain]:183.xx.xxx.xx
blue-a[domain]:183.xx.xxx.xx
[domain]:24.xxx.xx.xxx
[domain]:24.xxx.xx.xxx
[domain]:24.xxx.xx.xxx
mail.[domain]:158.xxx.xxx.xx
mail.[domain]:158.xxx.xxx.xx
mta-sts.an[domain]:183.xx.xxx.xx
mta-sts.blue-a[domain]:183.xx.xxx.xx
raya[domain]:183.xx.xxx.xx
www.an[domain]:183.xx.xxx.xx
www.blue-a[domain]:183.xx.xxx.xx
www.[domain]:183.xx.xxx.xx
www.[domain]:183.xx.xxx.xx
www.[domain]:183.xx.xxx.xx
www.[domain]:183.xx.xxx.xx
www.raya[domain]:158.xxx.xxx.xx

[*] Trello URLs found: 7
--------------------
https://trello.com/b/blagzqzl/india-business-r[domain]trations
https://trello.com/b/grflbrwz/customer-billing-schedule
https://trello.com/b/kil63azb/besoin-de-support-[domain]
https://trello.com/c/npdtcnk5/21-[domain]
https://trello.com/c/npzaomsn/3-[domain]-polska-sp-z-oo
https://trello.com/c/odjfmuqn/22-[domain]-m
https://trello.com/gal[domain]1

まとめ

  • theHarvester は 情報を集めるOSINTツール
  • Python 環境が構築されていれば使用可能

エンジニアとしての基礎をどう築くか -7年目エンジニアの振り返り -

社会人１年目、プログラマなりたての時に上司に言われていた言葉がある。

「急がば回れ。基礎を築きなさい。」

基礎がなければ、その上の応用的な技術など身につきません。

PHPを理解できていない方がPHPの FW を用いて Webアプリケーションを作ろうとしても、FWのルールに忙殺されてまともなものはできないでしょう。 基礎力が身についていなければ、公式文書を読んでも理解度が低くなることを想像することは用意です。

「基礎が大事」という言葉があったからこそ、エンジニアになって７年目になろうとしている今でも基礎を愚直に大事にしている自分がいます。

そんな若輩者の私にも後輩ができ、部下と言えるような方々ができるようになりました。技術的な指導を任されてもいて、基礎を気づく事の大切さを伝えています。

しかし、最近の悩みは技術者としての基礎をどのように築くかの、 How が思いっきり抜けてしまっていることです。

そこで今回は自分自身が基礎力をどう身につけたかを、次メンバーに話すタイミングがあったときのメモとして置いておこうと思います。

プログラマとしての基礎

繰り返し構文と条件分岐

プログラマとしての基礎は、まずは繰り返し構文と条件分岐だと考えています。

forとifですね。

どんなに簡単なプログラミング言語の入門書を手にとっても、このfor文とif文は最初の方のページに掲載されているものです。

個人的な感覚ですが、大抵のプログラムはforとifを書けないとまともに動くプログラムはできません。

これらを覚えるためには有名なfizzbuzzや、数年前にバズったズンドコなどを課題として与えてあげればいいかなと思っています。

クラスを意識させること

次段階として、クラスを認識することです。 クラスを理解できていない人には業務ロジック触らせません。

いわゆる、タイヤキクラスでも動物クラスでもいいです。 クラスを理解できればいい。 ※タイヤキも動物も例として微妙なので私はあまり使わないですが

個人的に教えていて一番反応が良かったのはポケモンですね。

from random import choice

class Pokemon():
    def __init__(self, name, attribute, moves, is_mega=False):
        self.name = name
        self.attribute = attribute
        self.moves = moves

    def attack(self):
        print(choice(self.moves))


class Pikachu(Pokemon):
    def __init__(self):
        name = 'Pikachu'
        attribute = 'thunder'
        moves = ['thunder shock', 'iron tail', 'Volt Tackle', 'Grass Knot']
        super().__init__(name, attribute, moves)

p1 = Pikachu()
p1.attack()

ポケモンクラスという親クラスがあって、ピカチュウやリザードンはポケモンクラスを継承して定義される。 is-a関係を表しやすいのもポイントです。

教えるときは、ポケモンクラスを例にして身の回りのものや自分の趣味のものをコードで表すように指示しています。 (ただ、あまりいい例が思い浮かばない・・・)

ちなみに、オブジェクト指向とクラスは別物という認識です。 オブジェクト指向を理解せずとも、一旦クラスは理解できるは。 クラスとオブジェクト指向を一度に理解しようとすると、難しすぎるので初学者にはクラスとオブジェクト指向は分離して教えるようにしています。 オブジェクト指向を理解している人が綺麗なコードを書けることを大前提として、後からジョインする人がクラスさえ理解できていれば、それらの綺麗なコードを参考にコードを書くことが可能です。

一つの言語に深く潜ること

一つの言語に深く潜って勉強することを教わりました。

それに従って、言語がどのようにメソッドを探索しているのかや、言語ごとの特徴を把握しやすいというメリットがありました。

例えば、私は Ruby が一番得意な言語だと自負しております。 というものの、Ruby でプログラム言語のノウハウを学んだと考えているからです。

Ruby は資格勉強(Silver, Gold)も行ったので愚直にメソッド名や動きを記憶しました。

また、メタプログラミングRubyも読んだので Ruby でメソッドチェーンなどを学びました。オブジェクト指向も同様です。

社会人3年目〜4年目で Ruby を愚直に勉強し、一つの言語に深く潜ったからこそ、その後PHPを勉強し直したときや、Pythonを学んだときは Ruby と同じような感覚で勉強を行うことができました。

IT関連の基礎を養うために読むべき本

本をたくさん読みました。

これも一年目の時に言われたのですが、本やクラウドに勉強として払うお金は自己投資と教え込まれたからです。

リーダブルコード

www.oreilly.co.jp

プログラム書く人なら言わずもがなの名著。 ソースコードをいかに読みやすく書くかのノウハウが詰まっている。 プログラムは書くことより読む事の方が多い。だからこそ、万人が読みやすいコードを書くことを心がけるって大事。 本の中身も冗談が入り混じっていて、とても分かりやすく、面白い。

プログラムはなぜ動くのか

www.amazon.co.jp

プログラムがなぜ動くのかを解説してくれている。 ぶっちゃけ、大学の講義とかで教わることができるレベルのことが、一冊に詰まっている。

ネットワークはなぜつながるのか

www.amazon.co.jp

プログラムはなぜ動くのかと同じ。 大学時代にこんな講義を受講したなーという思い出（講義内容は覚えていない←）

マスタリングTCP/IP

www.ohmsha.co.jp

プログラマではなく、ネットワークの知識が必要な時の鉄板本だと思っています。 ネットワークの歴史から書いてくれているのが、とても良い。

Webを支える技術

gihyo.jp

プロになるためのWeb技術入門

www.amazon.co.jp

まとめ

結局、自分がエンジニアとしてどう勉強してきたかの振り返りになった気がする。

これで基礎をどう築くかの問いに対しての答えを用意できたと思っています。

【駆け出しエンジニア向け】 Webアプリエンジニア出身の情報処理安全確保支援士がまとめる Web の脆弱性超基礎④ - 認証・認可の不備 -

概要

今回は少し変化球です。 サイバーセキュリティの世界では認証(Authentication)と認可(Authorization)という単語が存在します。

二つの単語はとても似ていますし、境が曖昧なエンジニアのかたをよく見かけます。

認証・認可とは

認証とは

Wikipedia より引用

認証（にんしょう）とは、何かによって、対象の正当性を確認する行為を指す。

認証とは、本人確認のことを指します。

例えば車を運転している時に検問などで警察官から運転免許書の提示を求められますね。 それと同じで、最近だとライブ会場でも本人確認のために、本人確認書類が求められます。

これらは、本人を確認するための行為です。 Webの世界では、主にパスワード認証が扱われています。

これから紹介するのは認証を行うために必要な3つの要素です。

知識認証

知識認証とは、利用者本人の記憶していること、知識をもとに認証する方法です。

具体例としてパスワード認証や、秘密の質問などが存在します。

特にパスワード認証はありとあらゆるWebアプリケーションのログイン機構として扱われており、ほぼ全てのメンバー管理機能を持つようなサイトで採用されていることでしょう。

利点としては、一般的に普及している認証方法なので、比較的万人に受け入れられやすいことでしょうか。

問題点としては、パスワードの管理が煩雑になりやすいということです。共通のパスワードを使いまわしたり(絶対だめ)、メモ帳などにパスワードを管理したりする。 パスワードの使い回しは言語道断だが、メモ帳へのパスワード記入などは、また別の脆弱性を生む可能性があり、パスワード管理はとても難しい。

パスワード管理ツールなり、パスワードをフレーズで覚えて使いまわさないようにする工夫などが必要になります。

物理認証

物理認証とは、物理的な要素を用いて認証をする方法です。

ITの世界では、OTP(One Time Password)などが有名ですね。 OTPは一定期間で変わるパスワードを発行するトークン機器やアプリを用いて、それらの情報で認証を行う方法です。

利点としては、物理的な物を持っていることで本人と認証することが可能であるという点で、知識認証などとは違い管理が煩雑になりません。 問題点としては、物理的な物を紛失、もしくは盗難に遭ってしまうと認証が突破されてしまう可能性があることです。

生体認証

生体認証とは、生体的な情報を用いて認証を行う手法です。 指紋や色彩、などの生体情報をデータ化して認証情報とします。

利点としては、知識認証、物理認証と比べて詐称するのが難しいという点。 問題点としては、実装が技術的に難しかったり、本人拒否率と他人許容率などのバランスが難しいと言ったものがあります。

多要素認証

多要素認証とは、本人確認のために複数の認証を用いる方法です。

上記の知識認証、物理認証、生体認証のどれか2種類以上を使って認証を行なっていれば、多要素認証という扱いになります。

1番身近な例としては銀行のキャッシュカードを用いたお金の引き落としなどが該当します。 お金を引き出す際は、キャッシュカードと４桁の暗号番号が必要だと思うのですが、これは物理認証と知識認証の二つを用いております。

また3つの要素を兼ね備えているのが、天空の城ラピュタの「バルス」ですね。 知識認証(バルス)、物理認証(飛行石)、生体認証(王家の血)という三つの条件が必要なので、バルスは三桁のパスワードで脆弱すぎwwwと言われるのを時々聞きますが、わりとバルス自体はセキュリティ的に固いことがわかります。

認可

認可とは、本人認証が終わった後に、その本人、もしくは役職や所属しているグループごとにに与えられている権限のことを指します。

運転免許証であれば、普通車や大型など、どの車種を運転することができるか？という部分が認可情報となります。

Twitter の連携アプリなどを開くと下記のような画面が表示されます。 これはTwitter の認証が終わった後、Twitter のどの機能に対してのアクセスを許可するかを確認する認可画面と呼ばれるものです。

f:id:UltraBirdTech:20200229172928p:plain

認証・認可の不備とは

認証の不備

認証の不備とは、本人確認の機能が十分ではなく、本人認証が行われずにWebの機能などを扱えてしまえることです。

例えば本来であれば、他人が知ることのできない情報で知識認証をしなければいけないところを、利用者の誕生日で認証ができてしまったりとかする場合は認証の不備があると言えるでしょう。

認可の不備

認可の不備とは、認可された権限では閲覧できないはずのフォルダなどにアクセスできてしまう場合は認可の不備が認められます。

例えば、社内システムで、経営層しかアクセス権を与えられていない資料に一般社員がアクセスできてしまうなどの問題があると認可の不備と言えるでしょう。

Webの世界では、会員サイトにおいて無料会員であるにも関わらず、有料会員ではないとアクセスできないページへアクセスしたり、機能を扱えてしまう場合は認可の不備にあたります。

対策

認証・認可の不備の対策としては、不備がないように実装することです。（何の対策とも言えていない）

まとめ

・認証とは本人確認のこと ・認可とは認証後の本人(役職)に紐づく権限のこと

おまけ — 個人的に利用しているパスワード管理ツールなど —

パスワード管理ツール

OnePassword 使用しています。 煩雑になりやすいパスワードを、マスターパスワード一つ覚えておくだけで全て管理してくれます。 アプリ、ブラウザ拡張があるので色々なデバイス、PCでパスワード管理を行うことができます。 年額がかかりますが、パスワードの使い回しをするくらいならツールに頼るという選択をしました。

1password.com

OTPアプリ

多要素認証が設定されているSNSやツールは全てOTP設定をしています。もしブルートフォースや、上記OnePasswordがハッキングされてパスワードが突破されても、多要素認証を設定しているので安心です。

Google Authenticator

Google Authenticator

  • Google LLC
  • ユーティリティ
  • 無料
apps.apple.com

play.google.com

やはり、セキュリティエンジニアとしてはこういう振る舞いから入るというのも大事なのかなと考えています。

【駆け出しエンジニア向け】Webアプリエンジニア出身の情報処理安全確保支援士がまとめる Web の脆弱性超基礎まとめ

Webの脆弱性超基礎の記事が多くなりそうだったので、まとめページ作っておきます。

筆者ようの備忘録です。(自己満足記事です)

新しい記事書いたら随時更新します。

【駆け出しエンジニア向け】 Webアプリエンジニア出身の情報処理安全確保支援士がまとめる Web の脆弱性超基礎④ - 認証・認可の不備 - - ばぁど・うぉっちんぐ

【駆け出しエンジニア向け】 Webアプリエンジニア出身の情報処理安全確保支援士がまとめる Web の脆弱性超基礎③ -CSRFの脆弱性編- - ばぁど・うぉっちんぐ

【駆け出しエンジニア向け】 Webアプリエンジニア出身の情報処理安全確保支援士がまとめる Web の脆弱性超基礎② -SQLインジェクション編- - ばぁど・うぉっちんぐ

【駆け出しエンジニア向け】 Webアプリエンジニア出身の情報処理安全確保支援士がまとめる Web の脆弱性超基礎① -XSS編- - ばぁど・うぉっちんぐ

【駆け出しエンジニア向け】 Webアプリエンジニア出身の情報処理安全確保支援士がまとめる Web の脆弱性超基礎③ -CSRFの脆弱性編-

超基礎まとめ記事第三弾です。

前回の記事はこちら。

ultrabirdtech.hatenablog.com

今回はCSRFの脆弱性です。

概要

CSRF(Cross Site Request Forgeries)の脆弱性とは、リクエストの強要とも言い利用者が意図しないリクエストを外部の攻撃者に実行されてしまう脆弱性です。

Webアプリケーションには、様々な重要な処理があります。 例えば、ブログの投稿処理や、オンライショップサイトの商品購入、オンラインバンクの入金処理など、本人ではないと許されないような処理が存在します。

これらは基本的にPOST処理でサーバー側では処理されるのですが、このPOST処理を行う際の処理に問題があると、CSRFの脆弱性が発生してしまいます。

これらの処理を正しい利用者が知らないところで、攻撃者によって行われてしまうことがCSRFの脆弱性です。

有名な事例としては、2005年の mixi で起きた「はまちちゃん」というものがありました。 https://www.itmedia.co.jp/enterprise/articles/0504/23/news005.html

CSRFの脆弱性の特徴としては、サーバーに届くリクエスト自体は正しいものになるというものです。 あくまでリクエストを送っている本人が利用者ではなく、攻撃者なだけでありサーバー側としては、サーバーに届いてくるリクエストが正しい利用者からのものなのか、攻撃者からのものなのかの判別をつけることができません。

対策

基本的な対策として重要なPOST処理を行う際にリクエストが正しいものかを確認する処理が必要になります。 対策としては主に3つが存在します。

1. トークン確認処理を行う

重要な処理を行う前の画面で、サーバー側から一意な値トークンを画面側に発行します。 画面側からは、このトークンをhidden属性に入れて重要な処理を行うパラメーターと一緒にサーバー側に送り返します。 サーバー側は、自分自身が発行したトークンと受け取ったトークンが一致するかを確認し、一致すれば正しいリクエストとして処理を続行します。

最近のWebフレームワークではこのトークンによる対策が進んでおり、基本的にはWebフレームワークのルール通り実装していれば、CSRFの脆弱性は防ぐことが可能です。

2. リファラーのチェックを行う

重要な処理を行う前の画面などがどこから来ているのかというRefererという属性が存在します。 そのRefererが、重要な処理を行う前の画面であるかを確認することでCSRFの脆弱性を防ぐことが可能です。 ※しかしRefererは改ざん可能であり、対策としては不十分の場合があります。

3. 重要な処理の前に本人認証(パスワード認証)を行う

CSRFの脆弱性の原因が、サーバーに送られたリクエストが正しい利用者からのものか判別できないからというものがあります。 正しい利用者であるかどうかが分からないのであれば、重要な処理の前で認証などを行なってあげれば良いのです。 パスワード認証であれば、基本的にパスワードを知っているのは利用者本人だけのため、パスワードを正しく入力できれば本人からのリクエストであることを証明できるでしょう。 特にオンラインバンキングなどの入金処理の前などは、パスワード入力などが求められる場合が存在します。

まとめ

・CSRFの脆弱性とはリクエストの強要のこと ・CSRF脆弱性に対する対策はPOST処理実行時のトークンの確認処理

【駆け出しエンジニア向け】 Webアプリエンジニア出身の情報処理安全確保支援士がまとめる Web の脆弱性超基礎② -SQLインジェクション編-

駆け出しエンジニア向け

どーも。ばぁどです。

前回の記事 Webの脆弱性①超基礎 -XSS編-はこちら。

ultrabirdtech.hatenablog.com

SQLインジェクション

概要

SQLインジェクションとは、開発者が意図しないSQLを流し込まれてDBの値の改ざん、秘匿情報の閲覧などが可能となってしまう脆弱性です。

実装したアプリケーションが値のエスケープを適切に行なっておらず、入力した値がSQLないで展開されてしまった場合、SQLインジェクションが発生してしまう恐れがあります。

WebアプリケーションとDBはとても親和性が高いです。 例えば通販サイトなどを作ろうと思うと、利用者の情報や商品の情報を管理する必要があります。 それらの情報はサーバー側で管理し、必要に応じて情報を取得、作成、更新、削除などを行います。

また、このDBの操作をするために作られた言語がSQLです。 SQLはSELECTやINSERT、UPDATE、DELETEなどの句があり、それらを扱うことでDBの操作を行います。

通販サイトなどでは、商品の検索機能などがあります。 検索機能が使用される場合、WebアプリとしてはDB側に下記のようなSQLを発行するとします。

SELECT * FROM PRODUCTS WHERE product_name = '★★';

★の部分は、Webアプリケーションから入力された値が入るイメージです。 この場合 ★★に入力された文字列と一致するproduct_nameのデータを持つデータがテーブルから検索されます。

PRODUCTSテーブルの例

カラム名 説明
product_id 商品を一意に識別するID
product_name 商品名
product_price 商品の値段
prodcut_detail 商品の詳細

テーブルに入っているデータ

product_id product_name product_price product_detail
1 パソコン 200,000 使いやすく、軽量なノートPCです。
2 マウス 3,000 黒、白、赤の三色からお選びいただけます。
3 キーボード 5,000 キーボード配列カスタマイズ可能です。

★★のWebアプリケーションから入力する値にパソコンという文字列を入力した場合は、下記のようなSQLが組み立てられ発行されます。

SELECT * FROM PRODUCTS WHERE product_name = 'パソコン';

こうすることで、名前がパソコンと完全一致するために、パソコンのデータを取得することができます。

情報の取得、値の改ざん

SQLインジェクションが存在すると仮定して、上記のWebアプリケーションからの入力に下記のような値を入力します。

入力値：a' OR 'A' = 'A' ; --

この値を入力することで下記のSQLが構築され発行されます。

SELECT * FROM PRODUCTS WHERE product_name = 'a' OR  'A' = 'A' ; --';

上記の結果が 「商品名がaの商品」(A) もしくは 「AとAが一致している(True)」(B) として処理されます。 OR条件なので、AとBのどちらがの結果がTrueであれば、この条件式の結果はTrueとなります。

WHERE句がTrueなのでPRODUCTテーブル全てのデータを取得するという条件になります。

本来であれば、商品名(product_name)と一致するデータ一件が手に入るSQLを発行しているつもりが、商品データ全てを取得するSQLが発行されてしまいます。

今回はデータの取得が主でしたが、同じようにUPDATEを用いることでデータの改ざん、DELETEでデータの削除、SQLインジェクションの場所によってはログイン認証の突破なども行えます。

対策

1. バインド機構を用いる

バインド機構とは、SQLを安全に発効するためにライブラリなどで用いられている機能のことです。 今回例題として扱った値(a' OR 'A' = 'A' --; )にはシングルクォーテーションが用いられています。

これらの'(シングルクォーテーション)が、SQL内で展開されており、'として扱われてしまうことが問題なので、適切に' をSQL構文の'として扱われないように実装をする必要があります。

それらは、各言語のライブラリやWebアプリケーションフレームワークが提供しているORマッパー(SQLを発行するライブラリ)などで実装されているので、それらを適切に扱いましょう。

まとめ

  • SQLインジェクションとは開発者の意図しないSQLが実行されること
  • 対策はバインド機構などを用いてSQLを安全に構築すること

参考

徳丸本

www.sbcr.jp

【駆け出しエンジニア向け】 Webアプリエンジニア出身の情報処理安全確保支援士がまとめる Web の脆弱性超基礎① -XSS編-

駆け出しエンジニア向け

どーも。ばぁどです。

もうすぐ7年目になるWebアプリエンジニア上がりの情報処理安全確保支援士です。(情報処理安全確保支援士歴は2020年度で3年目になります)

現在はセキュリティ関連の仕事をやったり、社内内部システムの開発などをしたりしています。

最近、社内で色々と若手に教える立場になっています。 一時期、講師業務もやっていたので、教えるということには少しはなれたのですが、いかんせんまとまった資料が手持ちでありません。

ネットを探せば、良い資料は沢山あって、筆者自身ブックマークは大量につけているのですが、自分自身で作った資料ほど扱いやすいものはありません。

そこで今回はブログ記事として資料を作ってみて、いつでも使えるようにしてみました。 あくまで本ブログ記事は筆者の自己満足ですが、読者の対象としては「IT未経験の新人、セキュリティ入門者」としております。

脆弱性とは？

システム上のバグ、ソフトウェアの設計、実装不備などを用いて、攻撃者に攻撃の侵入経路を与えてしまうようなセキュリティ上の欠陥のことを言います。 攻撃者はこれらの脆弱性を用いて、システム内部への攻撃(エクスプロイト)を仕掛けてきます。

脆弱性は様々な層で紛れ込む可能性があります。

ソフトウェアがのるサーバーに脆弱性が紛れ込んでいる場合もあれば、 人員的な配置や組織的な人に対する脆弱性というものもあります。

そして、ソフトウェア開発者であれば、セキュアコーディングを意識しないと、今回学ぶWebの脆弱性が紛れ込む可能性は大いにあります。

XSS (クロスサイトスクリプティング)

概要

Google Chrome や FireFox などの Web ブラウザ側で実行されるプログラム言語である JavaScript を悪用し、開発者が意図しないシステム的な動作をWebブラウザ側で起こす脆弱性です。

例えば下記のようなスクリプトが Web ブラウザで JavaScript として読み込まれるとダイヤログで "XSS の脆弱性が存在します。" と表示されます。

<script>
    alert("XSS の脆弱性が存在します。");
</script>

実行例 f:id:UltraBirdTech:20200223134551p:plain

これは Web ブラウザが というタグを認識し、タグで囲まれた内部の文字列を JavaScript として処理してしまうことによって起きてしまいます。

ちなみに、本来のクロスの綴りは(Cross)でCが大文字なのですが、Webでは html, JavaScript と並んでデザインを行う CSS( Cascading  Style Sheet )が存在し、それと区別するために X が用いられているようです。

XSSの具体例としては下記のようなものが挙げられます。

1. Cookieの中身が操作、覗き見られてしまう

クライアント、サーバー間で一意の存在として判断するために、よく Cookie というものが使われます。この Cookie の中にはサーバーから与えられた一意のIDなどの情報が含まれている場合があります。

例えば、下記のようなスクリプトを流し込まれてしまうと Cookie の中身が閲覧されてしまいます。

<script>
    alert(document.cookie);
</script>

f:id:UltraBirdTech:20200223134610p:plain

今回は例として Cookie の中身の閲覧を行いましたが、Cookieの閲覧ができるので Cookie の中身の書き換え(改ざん)なども行うことが可能であり、セッションIDなどが書き換えや奪取されてしまうとセッションハイジャックが行われる場合もあります。

2. 悪意のあるWebページへ強制的にリダイレクトされてしまう

JavaScript はブラウザ側で実行される言語なので、ブラウザ側の操作を行うことが可能です。 操作可能な挙動としては、画面の遷移を行うものも存在し、攻撃者が用意した悪意のあるWebページなどへ強制的に移動(リダイレクト)させられてしまう場合があります。

<script>
    location.href=’http://example.com’;
</script>

3つの種類のXSS

1. 格納型 XSS

格納型のXSSとは、サーバー側に格納された悪意のある JavaScript をブラウザでアクセスするたびに読み込んでしまうパターンのXSSです。 Webアプリで扱うデータはサーバー側でDBなどに格納する場合がほとんでです。

例えばブログサイトを一つ取ったとしても、ブログのタイトルや内容、閲覧者からのコメントなどを記事のデータとしてサーバー側に格納する必要があります。

外部から訪れた人でも入力できる閲覧者からのコメント部分に、上記のような XSS を引き起こすスクリプトを入れ込まれてしまうと、サーバーからデータを取得するたびに、JavaScript が読み込まれて実行されてしまいます。

格納型の怖いところは、一度サーバー側に悪意のあるデータが格納できてしまえば脆弱性が存在している間サイトを訪れた人全員がXSSに引っかかってしまうことです。

2. 反射型 XSS

反射型XSSとは、利用者が入力した入力値をブラウザ側で読み込んでしまうパターンのXSSです。 検索画面などに多いのですが、前の画面で入力した値を表示する場合が多いです。 この前の画面で入力した値を表示する部分に脆弱性が存在すると反射型XSSが成功してしまいます。

赤枠で囲まれているところにXSSの脆弱性が存在すると、キーワードに入力した JavaScript が発火してしまう。 f:id:UltraBirdTech:20200223141550p:plain

3. DOMベースXSS

DOMべースのXSSとは、XSSによりDOMを書き換えられてしまう攻撃です。 WebのHTMLはDOMという構造で管理されています。 そのDOMをXSSで書き換えて、Web利用者が意図しない動きを与えるのがDOMベースのXSSです。

対策

対策はいくつかあるのですが、基本的には入力された JavaScript をブラウザ側で JavaScript として認識させないことです。

1. 出力時の特殊文字のエスケープ

XSS 対策は基本的に出力時の特殊文字エスケープがされていれば防ぐことができます。

developer.mozilla.org

上記Mozillaのページより転載

文字 エンティティ 注記
< &lt; タグの開始として解釈
> &gt; タグの終了として解釈

XSS の原因とは、ブラウザ側で <script>という表記がHTMLのタグとして認識されていることが問題です。 ブラウザ側にサーバーで取得した値、または入力された値を表示する時に、これらのエスケープ処理をすることによってXSSは防ぐことができます。

システム的には&lt;や&gt;と解釈されていても、我々がブラウザで見るときは<や>としてブラウザは表示してくれます。

&lt;script&gt;
    alert("エスケープ処理されているためXSSの脆弱性は存在しません。");
&lt;/script&gt;

f:id:UltraBirdTech:20200223143053p:plain

2. データ格納時の特殊文字のエスケープ

こちらは、格納型のXSSにのみの対策になりますが、サーバー側へのデータ格納時にエスケープする処理を入れ込む方式です。 また、システムの仕様によってはサーバー側の言語で<script>という単語を取り除く仕様もたまに見かけます。

WordPress なんかは <script>という文字列を取り除く処理が、いくつかのXSS対策の一つとして採用されていました。

<script>という単語を取り除いてしまっても良いシステム要件であれば一考しても良いかもしれません。

まとめ

  • 脆弱性とはセキュリティ上の欠陥のこと
  • XSSとはブラウザ側で悪意のあるコードを流し込まれること
  • XSSには格納型、反射型、DOMベースの3種類がある
  • XSSの対策は特殊文字のエスケープ。これ絶対！

参考

サンプルコード

github.com

徳丸本

www.sbcr.jp