今さら聞けないセキュリティ　2021年12月15日

SPAでのバックエンド認証用トークンの管理方法に関する考察

Single Page Application (SPA) から呼び出すバックエンドAPIの認証トークンの管理方法について、Web上の文献やライブラリの実装を調査して、自分の考えを整理した。

### 前提

* 本記事はSPAにおいてバックエンド認証に使うトークンの管理方法（典型的にはLocal Storageに保管してよいか？Cookieを使うべきか？など）についての考察となる。認証トークンの仕組み（ステートフル vs ステートレス）については言及していない。
* ブラウザにはAndroidのKeyStoreのような仕組み（暗号化され、取得時に端末の認証が必要となるストレージ）がないという批判があるが、これも考慮から外している。（つまり、システム管理者やPCの共同利用者がCookie/Local Storageを参照して…というリスクについては考えていない。）

### 考察

* まず、そもそもの原因となるXSS脆弱性への対策が最も重要、というのは間違いない。
* XSS脆弱性によりアプリケーションのコンテキストでブラウザにコード実行させることができれば、認証トークンの管理方法

OpenChain Security Assurance Reference Guide

こんにちは！
3日連続で登場のENDOです。

今週はセキュリティやツールに関するトピックスをご紹介していますが、
本日はOpenChainが今年の夏に[リリース](https://www.openchainproject.org/featured/2021/08/12/openchain-iso-5230-security-assurance-reference-guide-now-available)したSecurity Assurance Reference Guideについて紹介させて頂きます。

#Security Assurance Reference Guideって？
2021年8月にOpenchainのSpecification WGが[リリース](https://github.com/OpenChain-Project/SecurityAssuranceGuide/tree/main/Guide/1.0)した組織がOSSのセキュリティを確保するためのガイドラインです。
このガイドラインはISOとなっているOpenChainの標準そのものに含まれるものではありませんが、

Sigmaルールのすすめ

自組織で検知能力を上げる方法の一つとして、ログ監視を行っている機器に検知ルールを実装する方法があります。しかしながら、検知ルールの作成は攻撃の検証や過剰検知がないか確認する必要があり、いくつものルールを作成しようと思うと大変です。ネットワークトラフィックではSnort、ファイルではYaraといったルールがありますが、最近ではログファイルに対しても実装することが多いと思います。
ログファイルを対象としているルールとしてSigmaルールがあり、今回はSigmaルールについて自分の知識の整理するためにもこちらの記事に記載しています。

何か誤りがありましたら、Twitterやコメントで教えてもらえると助かります。
また、何か追加で分かったことがあれば、こちらの記事に記載していこうと思います。

#1.Sigmaルールとは
Sigmaルールとはログファイルに対する汎用的なシグネチャフォーマットです。
ログファイルを対象にしていることから主にログファイルを集約している製品で利用することが多いと思います。Sigmaルールでサポートされている機器は以下となります。

＜サポートされている製品＞

+

暗号のすすめ

https://www.amazon.co.jp/%E7%8F%BE%E4%BB%A3%E6%9A%97%E5%8F%B7%E3%81%AE%E8%AA%95%E7%94%9F%E3%81%A8%E7%99%BA%E5%B1%95-%E5%B2%A1%E6%9C%AC-%E9%BE%8D%E6%98%8E/dp/4764905795/ref=sr_1_1

この本をお勧めします。
パスワードを狙った攻撃が増える中で、webauthnや物理キーアクセスなどが今後一般化していくと思われます。しかし、暗号の理解がないとこれらの仕組みは利用できないし、かえってユーザビリティを犠牲にしてしまいかねません。
来年あたりセキュリティブームが来そうなので、今から準備しておくのがいいと思います。
この本自体は認証とかセキュリティ技術の実践の本ではないですが、暗号理論の昔から現代までを詳しく解説してあります。暗号の現在を知るという意味ではいい本だと思います。

ちなみに私はスマホを買ったおかげでスムースにコロナの予防接種を受けられたり、スマホというデバイスを使うことで二要素認証などでかなりネット環境が安全

レインボーテーブルでパスワードを復元してみる

# どんな記事？
この記事は[NSSOL Advent Calendar 2021](https://qiita.com/advent-calendar/2021/nssol)の13日目の記事です。

突然ですがNSSOLでは社内イベントとしてCFTを行っていたりします。
CTFといっても一般的なものとは違い、技術的な側面だけではなく謎解き的な側面や社内の知識が必要な問題があったりしてわいわいと楽しんでいます。

ぼくは今年その運営として問題を作成しました。内容としては、ハッシュ値がDBから流出した + レインボーテーブルが与えられた想定で、平文のパスワードを復元するというものです。

# レインボーテーブルとは
## レインボーテーブルの利点
ハッシュ値から平文を復元する方法として素朴に思いつくのは、考えられる平文すべてに対してハッシュ値をあらかじめ計算しておく方法です。
しかし、たとえば64種類（英数小文字 + 記号）からなる8文字のパスワードを256バイトの長さのハッシュに変換したとすると、必要な記憶領域は `64^8 * 256 byte` というとてつもなく巨大な領域が必要と

Log4Shell 脆弱性の対策をした話

# Log4Shell 脆弱性(CVE-2021-44228)の対策をした話

## Log4Shell 脆弱性?
Java製のアプリケーション・ミドルウェアで幅広くつかわれている Log4j2 で、任意のコードを実行できる脆弱性が 2021/12/10(金) に発見され、Log4Shell という名前が付けられたようです。
ログに出力されるであろう箇所（ユーザ名やパスなど）に、jndi lookup を行う文字列を埋め込むだけで実行してしまうもので、容易に当該脆弱性をつけ、危険度の高い（各スコアで最高スコア）状態にあります。

週末ではありましたが、この土日緊急メンテナンスに入るサイトもいくつか見受けられ、業界が素早く対応していました。

脆弱性の内容については、[12/12のサイオスさんの記事](https://security.sios.com/vulnerability/misc-security-vulnerability-20211212.html)がわかりやすかったです。

## 自社の状況

自社では、社内で利用するためにいくつかのサービスを運営しています。
当然その中

Hasuraを使用するならチェック！ 確認すべきセキュリティ対策設定チェックリスト

この記事は[GraphQL Advent Calendar 2021アドベントカレンダー](https://qiita.com/advent-calendar/2021/graphql)13日目の記事です。

## はじめに
Hasuraという、DBテーブルから自動的にGraphQL APIを作成してくれるGraphQLサーバーがあります。

https://hasura.io/

「Hasuraって何？」という方は、以下の記事を読んでいただけると幸いです。

https://qiita.com/sho-hata/items/2dbd41be42662007071e

Hasuraには、APIをさまざまな攻撃から守るための設定が数多く用意されています。
**本記事では、HasuraでGraphQLサーバーを運用していくにあたり、設定しておくべきセキュリティ対策設定をチェックリストとしてまとめました。**
大半はドキュメントに書いてあることなのですが、日本語情報が少なかったこと＆実際に運用して気づいたドキュメントにも書いていないことも盛り込んでいますので、
Hasuraを使用している方に

Log4Shellの脆弱性が公開されました：Version 2.15.0にアップデートしてLog4j RCEを防ぐ

本記事は2021年12月10日に公開した英語ブログ[Log4Shell vulnerability disclosed: Prevent Log4j RCE by updating to version 2.15.0](https://snyk.io/blog/log4j-rce-log4shell-vulnerability-cve-2021-4428/)の日本語版です。


本日（2021年12月10日）、新たに重大な[Log4j](https://logging.apache.org/log4j/2.x/)の脆弱性が公開されました。[Log4Shell](https://techcrunch.com/2021/12/10/apple-icloud-twitter-and-minecraft-vulnerab

Cloudflare WAFのLeaked Credentials Checkを国内最速？で検証する

:::note info
本記事は2021/12時点の確認結果を元に記載しています。進化の早いクラウドサービスに関連する情報ですので、仕様は随時変化していく可能性がある点にご注意ください。また、セキュリティに関する機能ということもありますので、公開されている以上の内容には踏み込みません。
:::

クラウドフレアのWAFに**Cloudflare Leaked Credentials Check**(※)というルールセットがいつの間にやらリリース(GA)されたみたいです。本機能について日本語で書かれた記事が無さそう(2021/12時点)だったので、早速ですがこの機能を触ってみたメモを書いてみます！

※クラウドフレアのコンソール上では**Cloudflare Leaked Credentials Check**と書かれていますが、開発者向けドキュメントには**[Automated exposed credentials check](https://developers.cloudflare.com/waf/exposed-credentials-check)**という名称で記載されて

BurpのIntruderを遅延開始する方法

これはシーエー・アドバンス Advent Calendar 2021 13日目の記事です。

シーエー・アドバンス（CAAD）技術統括本部セキュリティチームの @syk_nakayamaです。
社内（グループ会社含む）サービスの脆弱性診断に関わる業務を行っています。
業務ではBurpSuiteという診断ツールを使用しているのですが、BurpSuiteの機能の一つであるIntruderを使用する際に「○○時間後に開始させたい」というようなことがあります。
その方法について解説していきます。

まず使用するBurpですが、v2021.4.3を使用してください。
v2021.5.1からIntruderの仕様が変わり、機能が削除されてしまっているため、古いVerのBurpでしか該当する機能が使用できません。
古いVerのBurpは以下からダウンロードできます。
https://portswigger.net/burp/releases/professional-community-2021-4-3

次に、v2021.4.3Burpを起動し、Intruder > Optionのタブを開きます。

Snyk CodeのVSCode拡張機能を使ってローカルで手軽に脆弱性チェックする

# はじめに

こちらの記事はアドベントカレンダー[Snykを使ってセキュリティにまつわる記事を投稿しよう！【PR】Snyk](https://qiita.com/advent-calendar/2021/snyk)の12日目として投稿しています。

Snykはオープンソースコードやアプリケーションコードの脆弱性スキャンが簡単に自動化でき、修復まで可能なセキュリティプロダクトです。単純なソースコード検査だけでなく、依存しているライブラリの脆弱性やコンテナイメージそのものをスキャンすることができ、非常に強力なツールとなっています。

個人的に**Snykの強みはローカル上で開発しているときから簡単に脆弱性チェックする仕組みが整っているおり、デベロッパーファーストなところ**かなと思っています。

そこで、今回はローカル上で簡単に脆弱性チェックできるSnyk CodeのVSCodeの拡張機能について紹介したいと思います。

## VSCodeにSnyk の拡張機能を追加する

VSCodeの左側メニューになる拡張機能から「snyk」と入力すると候補がいくつか表示されます。

一番上の「*

サイバーセキュリティ用語勉強~メールサーバ編~

サイバーセキュリティについて勉強中です。
今回はメールサーバ周りで気になっていた用語や仕組みについてまとめようと思っています。
（今まで用語が曖昧で逃げてました。。。）

内容
■メールサーバ種類
・SMTPサーバ
・IMAPサーバ
・POPサーバ
■セキュリティ用語(メイン)
・S/MIME
・OpenPGP
・SPF
・DKIM
・DMRAC
・SMTPS
・STARTTLS
・SMTP-AUTH
・IMAPS
・POPS
・OP25B
・IP25B
■その他備考
・BEC
・標的型攻撃メール
・MUA、MTA、MDAについて
・メール形式について

■メールサーバ種類
●SMTPサーバ
一言でいうと、メールを送信、転送するサーバです。
（SMTP（Simple Mail Transfer Protocol）と略さずに読むとわかりやすいですよね）
個人のPCに入っているメールソフト（OutlookやThunderbird）などからこのSMTPサーバにメールが送られ、
宛先アドレス管轄のメールサーバへと転送する役割があります。
ソフトウェアは、Sendmail、Postfix、qm

脆弱性を生み出しかけた話

#忘れもしない2021年夏
ITエンジニアになって１年と半分が過ぎて仕事にも慣れてきた時でした。
その時の業務は開発しているサービスのページに広告を表示して、そこを叩いたらあらかじめ設定されていたページへとばすものでした。

順調に実装を進めていって、問題がないか動作を確認していました。
その時は検証用の環境にデプロイをして確認をしていました。検証用の環境は自分以外にチームのメンバーも見れます。

その時にメンバーのベテランエンジニアさんからありがたいお言葉をもらいました。
「これ広告以外にも飛ばされね？」

実はパラメータには飛ばされる先のURLを仕込んでいて、広告をクリックしたときにそのURLに飛ばすようにしていました。
（あとから知ったのですがこの脆弱性を利用して意図しないリダイレクトを行わせることをオープンリダイレクト攻撃といいます）

この時は結構ヒヤッとしました。

#対策
オープンリダイレクト攻撃には対策として以下の2点があります

####そもそもパラメータで渡さない
穴があるなら埋めればいい。
外部パラメータで渡すのをやめれば、攻撃の穴を防ぐことができます。

##

世界はすぐそこに。標準化活動を通じて。

#はじめに
この記事はNTTテククロス Advent Calendar 9日目の記事です。

NTTテクノクロス株式会社セキュアシステム事業部、経営企画部広報室兼務、クロステックセンター兼務、TX-CSIRT兼務、アソシエイトエバンジェリスト、テクニカルプロフェッショナルの武井です。
肩書きが異常に長いです。簡単に言えば色々やっている人です。

社内だけではなく、社外でも日本ネットワークセキュリティ協会(JNSA)の関連団体の日本セキュリティオペレーション事業者協議会(ISOG-J)で活動し、副代表とセキュリティ連携ワーキンググループ(WG6)リーダーをやっています。

昨日は堀江さんのAWSの負荷試験のお話でした。今日はガラッと変わって会社の名義で活動しているITU-TにおけるX.1060の策定による国際標準化活動を通じて感じた、「世界は意外と近い」というお話をさせていただきます。
技術バリバリのお話とは少し角度を変えて、その技術やアイデアが世界に届く、それがみんなに使ってもらえるようになるまでには、というお話です。

# 国際標準とは
一口に「国際標準」と言ってみたものの、実際には

株式会社ゆめみ所属メンバの SSH 鍵強度調査

この記事は [YUMEMI Advent Calendar 2021](https://qiita.com/advent-calendar/2021/yumemi) 9 日目の記事です。

_──── SSH鍵強度は意識の高さ_

ということで、[弊社の GitHub Organization](https://github.com/yumemi) に所属しているメンバを対象に SSH 鍵の強度を調べてみました。

## 元ネタ

https://hnw.hatenablog.com/entry/20140705

## 調査結果
### 調査方法

1. [GitHub API](https://docs.github.com/en/rest/reference/orgs#list-organization-members) で Organization に所属するメンバ一覧を取得
– 非 Public な メンバについても取得する場合は、 `read:org` な scope の Personal access token が必要
1. メンバのIDを元に、登録されている公開鍵

Snykでコンテナのセキュリティハードニング 【Snykテクニカルサポートを使ってみた】

# はじめに
こちらの記事はアドベントカレンダー[Snykを使ってセキュリティにまつわる記事を投稿しよう！【PR】Snyk](https://qiita.com/advent-calendar/2021/snyk)の9日目として投稿しています。

Snykは脆弱性スキャンが簡単に自動化でき、修復まで可能なセキュリティプロダクトです。単純なソースコード検査だけでなく、依存しているライブラリの脆弱性やコンテナイメージそのものをスキャンすることができ、非常に強力なツールとなっています。

この記事では、わざと脆弱性を入れ込んだコンテナイメージを作り、Snykで検知できるかどうか試しました。
また、人気のあるOSSライブラリを検査し、見つかった脆弱性にパッチできるPRを自動でSnykから生成してみます。

# Snykの脆弱性スキャンの仕組み

## ルールベース＋機械学習モデルでの精度向上
メインの脆弱性スキャン自体はルールベースの一般的なやり方です。それにフィルタとして、**機械学習ベースのモデルで偽陽性・偽陰性を少なくし、検知精度を上げている**ようです。

また、脆弱性の検知ルールとし

無線LANのセキュリティについて図解でざっくり理解する

こんにちは！
TechCommitアドベントカレンダー8日目を担当するあみぃです。
私は今CCNAの勉強をしているのですが、無線LANのセキュリティで訳分からん略語がたくさん出てきて理解しにくかったので、図解してみました。

CCNA勉強中の人はぜひ参考にしてほしいですし、そうでない人も、普段何気なく使っている無線LANはこうして守られているんだというのを知る機会にしていただけたらと思います！!

#無線LANの危険性
無線LANでは、データが有線を伝ってではなく、空気中を飛び交います。
ということは、

・盗み見

RISKENで社内のAWSアカウントのセキュリティを改善した話

# :sweat_drops: 背景
– ウチでもAWSとか使ってるけど、インフラのセキュリティ対策状況ってそもそもどんな状況なの❓
– ちゃんとモニタリングしてなにかあったらアラートされるようにしておかないと危なくない❓ :scream:

# :thinking: OSSにもなったRISKEN使おう
## RISKEN is 何❓
>`システム環境に潜む リスク情報 を継続的に収集・モニタリングするための セキュリティ オペレーション プラットフォーム です`

[引用元] [RISKEN – RISKEN](https://docs.security-hub.jp/)

>1. RISKENを利用することでセキュリティの問題を発見することができます
1. セキュリティインシデントを未然に防いだり、事故発生時にも調査・対応を行うためのツールとして活用できます
1. また、開発チーム、クラウド管理者、セキュリティ担当者の成果を可視化し、プロダクトオーナーとのコミュニケーションにも役立ちます

AWSやGCPなどのパブリッククラウド環境の利用状況をセキュリティの観点でモニタリングを実

BIツール利用で忘れちゃいけない、データ活用に潜むセキュリティリスクと予防策

この記事は[モチベーションクラウドシリーズアドベントカレンダー2021](https://qiita.com/advent-calendar/2021/mcs)の7日目の記事です。

本記事では、社内でBIツールを利用したり、これから導入を考えているエンジニア向けに、BIツールを用いてデータ活用をする際に気を付けたいセキュリティ面でのポイントを紹介します。

## データ活用と情報漏洩リスクは表裏一体
昨今のデータ活用の機運の高まりや、安価で高度な分析や可視化ができるBIツールの普及に伴い、より気軽にデータ分析が行える環境が整ってきました。

ここで、データを活用して事業成果を出そうとするほど、営業秘密や顧客情報など、機密データを取り扱う機会が増えるのではないでしょうか？

つまり、データは企業活動において価値を生み出す資産であると言えます。（唐突に余談ですが、明日の記事を書く東山さんは、整形されていないデータをう○こであると言います）。

資産は往々にして脅威の標的になるものです。企業の情報資産が漏洩してしまった場合、競争力の喪失や社会的信用の失墜など、企業そのものの存続にも関わり

セキュリティ関連のガイドラインや参考資料

セキュリティ関連のガイドラインや参考資料等について個人的にまとめていたものをメモとして共有します。

##経営層／幹部向け
* [サイバーセキュリティ経営ガイドライン](https://www.meti.go.jp/policy/netsecurity/mng_guide.html)

* [サイバーセキュリティ経営ガイドライン解説書](https://www.ipa.go.jp/security/economics/csmgl-kaisetsusho.html)

* [CISO ハンドブック](https://www.jnsa.org/result/2018/act_ciso/index.html)

* [「CISO等セキュリティ推進者の経営・事業に関する役割調査」報告書について](https://www.ipa.go.jp/security/fy29/reports/ciso/index.html)

* [サイバーリスクハンドブック　取締役向けハンドブック　日本版　経団連](https://www.keidanren.or.jp/policy/cybersecurity/Cy