免責事項 こちらの記事で紹介する内容は、教育目的または脆弱性について仕組みを理解し周知、啓発を行うためだけに作成しております。 ぜったいに、悪用しないでください。 記載されているコードを実行した場合に発生した損害には一切責任を負いません。 理解される方のみ下にスクロールしてください。 経緯 2021/12/9にて、超有名なログ出力ライブラリであるlog4jの第2世代で任意コードが実行可能であると報告されました。 Apache Log4j2 jndi RCE#apache #rcehttps://t.co/ZDmc7S9WW7 pic.twitter.com/CdSlSCytaD — p0rz9 (@P0rZ9) December 9, 2021 ※上記は特定の文字列をログ出力させることで、ペイントツール(draw.exe)を実行している Minecraft(Java版)のチャット機能にてこ
この記事では、以下のようなチームを想定して、お金と手間をできるだけかけずにそこそこセキュリティを向上させることをまとめようと考えています。そんなんじゃだめだ!とか、こういう場合は漏れませんか?というコメント大歓迎です。 想定するチーム 営業やCS、マーケの人など全職種含めると30人前後あるいはそれ以下で、Webサービス(アプリ含む)開発を行っている 副業人材も多く、半数のメンバーは会社支給でないマシンを使っている それらのマシンは他社の業務でも使用されている Macが多めだがWindowsもいる 基本的に業務データはクラウド上にあり、PCローカルにあるのは開発途中のデータ、Biz/バックオフィス系のドキュメント、重たいデザイン系データ程度。自社データセンターや、オフィスネットワークでしかアクセスできないサーバはない。 メインの業務ツールはGoogle WorkspaceとSlackとGit
Intro iOS15 がリリースされたため、 Private Relay のベータを試すことができた。 このようなサービスが提供されるようになった背景を踏まえ、挙動を簡単に確認しつつ、解説する。 背景 そもそも、なぜこのようなサービスが出てきたのかを理解するには、現在のインターネットが抱える問題の背景を理解する必要がある。 特に Web において問題になっている「トラッキング」を防ぐために、法的な規制や業界団体の自主規制による対策は長いこと行われてきたが、それでも看過できないインシデントなどが目立ったために、 Apple の ITP を皮切りに 3rd Party Cookie の制限が始まった。 ここで重要なのは、「本来防ぎたいのは 3rd party Cookie という技術ではなく Tracking というユースケースだ」という点だ。 この前提が伝わっていない場合、トラッキングのユ
Kernel/VM探検隊はカーネルや仮想マシンなどを代表とした、低レイヤーな話題でワイワイ盛り上がるマニアックな勉強会です。光成氏は、WebAssemblyにおける多倍長演算の実装について発表しました。全2回。前半は、ペアリング暗号とx86-64の計算方法について。 ふだんはペアリングを使った暗号化技術の研究や実装を担当 光成滋生氏:「WebAssembly向け多倍長演算の実装」について光成が発表します。 簡単に背景を紹介したあと、実装についてIntelのx64における多倍長演算の歴史を紹介して、WebAssemblyでの戦略を紹介します。 自己紹介です。SNSやGitHubでは@herumiで活動しています。Intelや富岳でのJITやAI関係の最適化をしていて、今日はそちらではなくて暗号とセキュリティに関するR&Dの中の、ごく一部を紹介します。 私は主に、ペアリングを使った暗号化技術の
CTO室 @ken5scal です。座右の銘は「当社はブロックチェーンの会社ではもうありません」です。 主にインフラ構築・運用をしたり、社内の基盤を整えたり、不具合を特定して git blame したら自分のcommitで泣いたりしています。 当社は「すべての経済活動を、デジタル化する」というミッションを掲げており、生産性向上の達成という価値を新しいサービスによって提供しています。 しかしながら、新しい価値にはリスクが伴います。信頼できない価値を提供するサービスを採用する合理的な判断はありませんので、お客様に価値を価値のまま提供しなければlose-loseな関係になってしまいます。 今回は2021/08/27に発表されたISMS認証の基準準拠を含む、「LayerXは信頼できる」ブランドを確立していくための当社のITガバナンス活動について触れようと思います。 prtimes.jp ガバナンス
CTO室情報システム担当の吉澤です! 前回ISMSとPマークの違いについて 書かせていただきました。 今回も引き続き紹介させていただきます。 先日、ISMSの内部監査を行いました。ROXXでは2回目、私のキャリアとしては初の監査となりました。 今回の記事ではこの内部監査にお話します。 監査に必要なタスクの洗い出し 監査に備え、必要なタスクを洗い出しました。 マインドマップを利用したので、イメージをつかんでいただければと思います。 このマインドマップで全体のタスク量を把握しつつ順に準備を進めていきました。 各部署へのヒアリング内容 具体的な業務は各部署ごとにヒアリングをしながら項目の確認をすすめていきます。 ヒアリング内容は主に3点を担当しました。 情報資産の洗い出し リスクアセスメント 教育 3点とはいえ業務としては多岐にわたっていたので、作業として最も時間を要したリスク管理について書いて
おはようございます、ritouです。 先日のWWDC2021の "Move beyond passwords" というセッションにて発表された "Passkeys in iCloud Keychain" という仕組みについてどんなものかを紹介します。 developer.apple.com WebAuthn 数年前からパスワード認証を置き換えると言われ続けている認証技術の一つである "WebAuthn" (やFIDO)という技術をご存知でしょうか。(ご存知ない方は "WebAuthn builderscon" "WebAuthn droidkaigi" などで検索してみましょう) 今回の話をするにあたって、WebAuthnがどんなものかをある程度理解しておく必要があります。 公開鍵暗号の仕組みを利用 パスワード認証のようにユーザーとログイン対象のWebアプリケーションがパスワードを共有する
PostgreSQLの行レベルセキュリティと SpringAOPでマルチテナントの ユーザー間情報漏洩を防止する (JJUG CCC 2021 Spring) Webアプリケーションにおいて、マルチテナント型、つまり複数のユーザー組織がアプリケーションとデータベースを共有する構成にすることがあります。この構成の持つリスクとして、万が一バグにより他テナントの情報が見えてしまうとそれは情報漏洩となり、重大なインシデントとなってしまうことがあります。この重要性を考えると、「気を付けて実装する」だけではなく、仕組みで漏洩を防ぐような対策には価値があります。 そこで、今回はPostgresSQLの行レベルセキュリティと、SpringAOPによる処理を組み合わせて、ログインしているテナントのデータにしかアクセスできなくする仕組みを実現しました。 導入にあたり考慮した複数の選択肢、乗り越えたいくつかの壁
バックエンドの構築を最短化することができることで有名な、GoogleのFirebase。 煩わしいサーバーの構築をスキップし、目的のウェブアプリケーションやモバイルアプリケーションを構築できるmBaaS(mobile Backend as a Service)と呼ばれる類のクラウドプラットフォームです。 しかし、その便利さの陰で見逃されがちなのが、セキュリティ。 手軽な開発を進められるその裏で、世に生み出されたプロダクトにはFirebase特有の脆弱性が大量に潜んでいることをご存知でしょうか? 今回はFirebaseにまつわる脆弱性や、Firebaseを用いるうえで実際に気を付けるべきセキュリティについて、Flatt Securityにて執行役員を務める豊田恵二郎さん、セキュリティエンジニアの梅内翼さん・ぴざきゃっとさんの3名へお話を伺いました。
ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx that is developed by Trustwave's SpiderLabs. It has a robust event-based programming language which provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring, logging and real-time analys…
Firestore の JavaScript SDK では、withConverter() を使うと任意のコレクションに型をつけたり自動でデータをデコード/エンコードしたりできますが、コレクションの親子関係の情報は持たないので、SubCollection や Parent を参照するときは毎回手動で withConverter を呼び出さなければなりません。 また、Firestore のセキュリティルールで書き込み時に型チェックをするには手動でルールを記述する必要があり、構文も複雑になりやすいので、できれば TypeScript の型情報から自動でルールを生成したいところです。 Fireschema を使うと、スキーマを宣言的に記述するだけで、親子関係を考慮したデータの型付け、デコード、セキュリティルールの生成などを自動で行うことができます。 Fireschema の機能 Firestor
ARR20億円を3年で達成したエンジニア組織が実現したDeveloper eXperience~3つの落とし穴と乗り越え方~(ver2)
The Go gopher was designed by Renee French. (http://reneefrench.blogspot.com/) The design is licensed under the Creative Commons 3.0 Attributions license. 種々の linter が様々なプロダクトの品質を高めてきた、というのは疑う余地のない事実です。実装の初歩的な問題をエディタ内や CI/CD パイプライン中で機械的に検出できる環境を作れば、開発者はコーディングやコードレビューの邪魔になる些末な問題を早期に頭から追い出し、本質的な問題に集中できます。 また、そのような環境づくり(e.g. linter のルールセットの定義、組織独自のルールの作成、…)は、まさに開発組織のベースラインを定義する作業として捉えることができます。一度誰かが定義
こんにちは、株式会社Flatt Security セキュリティエンジニアの梅内(@Sz4rny)です。 本稿では、Cloud Firestore (以下、Firestore) を用いたセキュアなアプリケーション開発を行うためのアプローチについて説明するとともに、そのアプローチを実現するセキュリティルールの記述例を複数取り上げます。 本稿を読むことで、そもそも Firestore とは何か、どのように Firestore に格納するデータの構造を設計、実装すればセキュアな環境を実現しやすいのか、また、Firestore を利用するアプリケーションにおいてどのような脆弱性が埋め込まれやすいのかといったトピックについて理解できるでしょう。 なお、本稿は以前に投稿した記事と共通する部分があります。理解を補強するために、こちらの記事も適宜ご覧ください。 flattsecurity.hatenablo
Googleは、オープンソースで開発されているソフトウェアの脆弱性がどのバージョンで生じ、どのバージョンで修正されたかなどの詳細をデータベース化する「OSV」(Open Source Vulnerabilities)プロジェクトの開始を発表しました。 オープンソースはクラウド基盤からアプリケーションまで、さまざまな場所で重要な役割を果たすようになってきています。そのため、正確な脆弱性情報の管理もまた重要さを増しています。 OSVにより、オープンソースソフトウェアの開発者やメンテナは手間がかかっていた脆弱性の報告が容易になります。 利用者はオープンソフトウェアの脆弱性がいつ修正されたのかなどの正確な情報を簡単かつ一貫した方法で得られるようになり、利用するソフトウェアの脆弱性の管理と対応を迅速かつ容易にできるようになります。 バグの再現手順を提供すればOSVが自動的にバージョン情報などを探索
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く