「セキュリティ」の記事 - Crieit

【セキュリティ】スイッチのポートセキュリティ

2021-07-12T13:59:06+09:00

まず、ポートセキュリティとは

ポートセキュリティとは、その名の通り、スイッチに接続するポートに対してのセキュリティです。

知らない機器がスイッチポートに繋がってLAN接続するのを防ぎます。
インターフェースコンフィギュレーションモードにて
switchport port-security
で有効にします

ここで、

switchport port-security maximum 3
とか設定すると、このスイッチには最大３台までしか接続できなくなる。

これを超えて6台とか繋いだら、
セキュリティ違反モードが作動します。

セキュリティ違反モードとは

違反すると何が起こるかというと、

セキュアなMACアドレス以外のパケットを破棄する
SNMPトラップやSyslogメッセージの送信と、違反カウンタの増加
ポートのシャットダウン

です。。。が。

これは違反モードがshutdown（デフォルト）の時の話。

違反モードは3つ（shutdown、restrict、protect）あって

restrictにすると、
3. ポートのシャットダウンがなくなり

protectにすると、
2. SNMPトラップやSyslogメッセージの送信と、違反カウンタの増加がさらになくなります。

XSSについてちゃんと調べてみた

2021-05-27T12:11:46+09:00

はじめに

OWASP ZAPで脆弱性診断を行ったところ、クロスサイトスクリプティング(DOMベース)　というのが出てしまいました。
XSS自体はよく聞くので知っていましたが、「DOMベースって何？そもそもXSSのことちゃんと理解してないな？」
と思い調べてみたので、まとめていきます。

XSSとは

Webサイトの脆弱性を突き、攻撃者がそこに悪質なスクリプトを仕掛ける攻撃です。
画面を一時的に改ざんしてログイン情報を抜き取ったり、Cookieを盗み見たりなど、とにかく危険満載って感じです。

XSSには以下の3パターンがあります。

反射型

フォーム入力などを行った次のページで発生するヤツです。
こちらの例を使用させていただきます。

検索画面で、ユーザーが「HTML5」と入力すると、
http://example.jp/search?q=HTML5というURLで検索結果が表示されるとします。

検索結果画面では、よく「◯◯を検索しました。◯件見つかりました。」みたいなのがありますよね。
その部分がHTMLで以下の様になっているとします。

語句「HTML5」を検索しました。20件の文書が見つかりました。

ユーザーが入力した「HTML5」をそのままspanで囲んで出力している感じですね。

これにもし、検索キーワードとしてなんてものを入力された場合

語句「」を検索しました。20件の文書が見つかりました。

となってしまいます。

本来文字列として表示されるべき部分が

と入力して投稿→DBに保存されたとします。

他のユーザーが掲示板を開くとこの攻撃者からの投稿が表示され、
JavaScriptが勝手に実行されてしまい、XSSが発生します。

DOMベース型　

JavaScriptがDOMを構築するときに発生するヤツです。
今回起きてたのはコレですね。
こちらの例を使用させていただきます。

以下のようなコードがあるとします。

div = document.getElementById("info");
div.innerHTML = location.hash.substring(1);

location.hash.substring(1)でURLのハッシュ部分(#以降)を取得し、
それをid="info"のdiv要素に入れることで、画面に表示させている処理です。

URLがhttp://example.jp/#title1みたいなものなら問題ないですが、
http://example.jp/# のようなURLを開いた場合、
　がHTML内に展開され、JavaScriptが実行されることでXSSが発生します。

困ったことに全く心当たりがない

今回起きた（診断された）DOMベースのXSSが何なのかはわかったけど、
自分のコードにおいて心当たりが全く無い！
フロントエンドはVueで作成しているので、VueにおけるXSSについても調べる必要がありそうだなと。
OWSP ZAPの誤検知の可能性もあるので、万が一明確な原因が見つかったら、またまとめておこうかなと思います。

参考

【セキュリティ】cookieとセッション、セッションハイジャックとは

2019-09-18T23:38:34+09:00

cookieとセッション、セッションハイジャックとは

※あくまで個人の見解での説明であり、厳密の意味とは異なる場合があります。

1. cookieとは

途中まで画面に項目を入力していて、前の画面に戻らないといけないってなったときに全部やり直しっていうのはなかなかしんどい
そんなあなたのためにウェブサーバとウェブブラウザ間での情報を保管してくれるのがcookie
開きなおして大量の情報が保持されてる時の安心感

cookieを消すことができるのはウェブブラウザ側
つまり見ようと思えばだれでも見られるところに情報がある
個人情報やらクレジットカード情報やらは入力面倒だろうけど、保持されないほうがいいね

2. セッションとは

サーバが発行するのがセッション

ウェブサーバとウェブブラウザは忍者
互いの合言葉を毎回確認しないと気が済まない
サーバが番号を発行してセッションIDをつくり、ウェブブラウザ側がそのセッションIDを使っていればサーバのデータを閲覧更新削除できるやったー

違ってたらもちろんデータに手は出せない

でも悪い奴らはそのデータに手を出したい

そうさセッションIDが分かれば悪さができてしまうのだ

3. セッションハイジャックとは

ハイジャックってのは、飛行機乗っ取りとかでよく聞く
セッションハイジャックはサーバデータをなりすましてもってっちゃう
セッションIDを推測やら盗聴やらでゲットできちゃったらデータはおしまい

4. セッションハイジャックを防ぐには？

忍者は必要
ただし忍者にも複雑なセッションIDにも限界はある
門番とか関所とかも準備しとこう

おわり

誰にでも分かる易しい情報漏洩のしかた - 基礎編

2019-01-30T09:07:41+09:00

最近peingにてTwitterのトークンなどが流出する問題が発生しました。しかしこれは何も知らなければ簡単に作り出せてしまう脆弱性です。具体的にどのようにしてこの情報漏洩が発生したのか、そしてどのようにして防ぐことができるのかのざっとの基礎について書いてみます。（ちなみに特に続きの記事はありません）

そもそもなぜ情報漏洩したのか

ユーザーの情報を表示する昔ながらの方法

例えば下記のような構造のusersテーブルがあったとします。

カラム	役割
id	ID
name	名前
twitter_token	TwitterのAccess token
twitter_secret	TwitterのAccess token secret

Webサービス上にてユーザーの名前を表示したい場合、例えばPHPのLaravelであれば下記のようにして表示します。

お名前：{{ $user->name }}

データをMySQLから取得後、メモリ上にはTwitterのトークンなどが存在しますが、ここではテンプレート上で名前しか表示していないので問題はありません。わざわざトークンを表示する、ということもないと思うのでこういった場合には問題になりません。

ユーザー情報をAPIで取得する場合

最近はフロントエンドとバックエンドが分かれることが多くなり、直接テンプレート上に表示する形ではなく、バックエンドから情報をJSON形式に変更してフロントエンドに伝える、という形が多くなりました。

例えばユーザー情報をPHPのjson_encodeでJSONに変換すると、下記になります。

{
  "id": 154,
  "name": "taro",
  "twitter_token": "weojwaiofj09a9aw9efjaw0efoawj2j3io2f",
  "twitter_secret": "ojweiofjaoiejfajewkljfaoiwejf"
}

当然のことながら、表示したいところだけではなくユーザー情報全てがJSONに含まれています。これを送信するため、ChromeのDev Tool等では丸見えになります。こういったことが今回の原因の一つになっています。

情報漏洩しないための対策

送信する情報を制限する

古き良き形と同様、単に表示したい情報をフィルタリングすればよいだけです。

データベースから取得する際に制限する

例えば、MySQLからデータを取得する場合、

SELECT * FROM users

のようにして全部取得するのではなく、

SELECT id, name FROM users

のように必要な情報だけを取得するようにします。メモリの無駄な消費も避ける事ができます。

アプリケーションフレームワーク側で制限する

例えばLaravelの場合、モデルの設定でJSON化する情報を設定することができます。

protected $visible = ['id', 'name'];

上記のようにすればIDと名前しか表示されませんし、

protected $hidden = ['twitter_token', 'twitter_secret'];

上記のようにすれば隠したいカラムを指定することができます。

Railsの場合もto_jsonに:onlyや:exceptを指定することができます。

Goの場合、構造体に対してJSONの出力方法を指定する形になります。

type User struct {
    Id int                   `json:"id"`
    Name string              `json:"name"`
}

設定は省略できますが、大文字そのままで使うということもあまりないと思うのでだいたい設定するのではないかと思います。なので設定中に「あれ、tokenってJSONに含めていいんだっけ…？」と勘のいい人であれば気づくことができます。このようにセキュリティをしっかりするためにわざわざちょっと面倒な言語やフレームワークを使う、という選択肢もあるのではないかと思います。

もちろん知識があれば選択は自由ですが、それでも人間が作っているものですのでいつも不安は残ります。

そもそも情報漏洩しても問題ないデータ構成にする

今回の件でせせりさんもツイートされていましたが、人為的なミスは起こる可能性がありますので、その場合にも問題ないデータ構造にしておく、ということも重要です。

例えば今回の例であればIDと名前はusersテーブルに入れておき、Twitter関連の情報はsocialsテーブルとして分けて入れておく、という具合です。これであればたとえusersテーブルのJSON生成方法をちゃんと設定しなかったとしてもTwitterのトークンが漏洩するということはありません。（元々せせりさんはこのように作っていたらしいですが、サービス譲渡後に変わってしまったようです）

まとめ

このように、正直情報漏洩は非常に簡単に行うことができますので、恐らく漏洩しているアプリは現時点でも非常に多いのではないかと思います。今回の騒動を見てダサいとか、対岸の火事だとか思わず、良い機会なので改めて自分で作っているサービスがあれば見直してみたり、セキュリティに付いてもっと深く調べてみると良いと思います。

「世界最悪のログイン処理コード」ではない可能性は無いのか？

2018-08-14T23:07:38+09:00

先日「世界最悪のログイン処理コード」が話題になった。

世界最悪のログイン処理コード。実際のサービスで可動していたものだとか……https://t.co/C2bG93ZCkj pic.twitter.com/EfVNAEslrn
— はっしー@海外プログラマ🇳🇿元社畜 (@hassy_nz) 2018年8月10日

ただ、開発者がその脆弱性を理解した上で、ちゃんと対処を行っており問題ない状態である可能性はないかを考えてみた。

一番の問題

今回のコードで一番問題になっているのはやはりここだろう。

var accounts = apiService.sql(
  "SELECT * FROM users"
);

生のSQLをサーバーに送って実行した結果をクライアント側で取得できるようにしていることで、第三者があらゆる情報を取得できてしまう脆弱性と、クライアント側にて大量のメモリ使用を強制させて負荷を与えるという問題をたった三行で想像させてしまう恐ろしいコードだ。

でも、ちょっと考え方を変えるとそうではない可能性もあるということが分かる。

SQL文をフィルタリングしている

もしサーバー側で送られてきたSQLをフィルタリングして、許可していないSQLを弾いている場合はデータベースのあらゆる情報をとれてしまうということはない。

そもそもSQLをそのまま実行しているわけではない

SELECT * FROM usersというSQL文を引数として渡しているが、これを必ずしもサーバー側でそのまま実行しているとは限らない。そもそもapiService.sqlというメソッドが引数だけを使って処理をしているとは限らない。

色々総合すると下記の様な感じになっている可能性もある。

JavaScript側

class ApiService {
  sql(query) {
    const response = $.ajax({
      url: "/api/sql",
      type: "get",
      async: false,
      data: {
        username: $("#username").val(),
        password: $("#password").val(),
        sql: query
      }
    });
    return response.result;
  }
}

サーバー側

$methods = [
  "SELECT * FROM users" => "getLoginUser",
  :
];
$this->{$methods[$request["sql"]]}($request);

getLoginUserの中でSELECT id, nickname FROM users WHERE username = '$username' AND password = '$password'みたいなのを実行して結果を返す感じ。

こんな感じであればセキュリティ的にもメモリ的にも全く問題はない。

ただしもちろんAPIのURLを別にすればいいだけでSQL文でフィルタリングする必要性も全く無いし、誰がどう見てもSQLを直接動かしているようにしか見えないので実装的にはとんでもない話ではあると思う。

生パスワードを使ってる問題

次に問題となるのは入力されたパスワードをそのまま使っている、つまりデータベースにも生のパスワードが保存されているのではないか疑惑。これに関しては先程のようにサーバー側で単なるSQLを直接実行しているわけではないという前提であれば疑惑を回避できる。

ただ、account.password === passwordという処理があるせいで、やはり生パスワードを使っていないとおかしいのでは、という話になってしまう。

ただここは一応$("#password").val()は必ずしも#passwordが入力欄とは限らないので、例えば#password_inputに入力されたものを随時サーバーに送って、ハッシュ化したものを#passwordというhiddenに入れておく、という可能性があり、それであれば特にその部分の問題はなくなる。

もちろんこのコードにするためにわざわざ通信して変換しているという処理は理解し難い。

まとめ

一応「世界最悪のログイン処理コード」であることを回避することができるような考え方は不可能ではなさそうだが、そのかわり今度は人としての優しさを失ったコードになってしまいそう。