JJUG CCC 2024 Fall 2024-10-27 https://jjug.doorkeeper.jp/events/177443
JJUG CCC 2024 Fall 2024-10-27 https://jjug.doorkeeper.jp/events/177443
はじめに こんにちは。久々に寝坊やらかして凹んでる、SST研究開発部の小野里です。今年入ってきた新人さんたちは、私のようにならないでほしいと祈るばかりです。 さて、新年度には入ってしまいましたが、つい先日まで2021年度新卒研修最後の延長戦として、以前話題になったLog4Shell脆弱性のPoCを作るという課題に取り組んでいました。やっと動作するところまでいったものの、ここまでの道のりは非常に果てしなく複雑で長く険しいものでした。 セキュリティ業界において、多くの場合脆弱性の詳細な再現手順は伏せられる傾向にあります。それは主に悪用を防ぐためなのですが、セキュリティの初学者には実際の所何をどうするとどう危ないのか、分かりづらい場合も多いのが現状です。 Log4Shell脆弱性は非常に大きな騒ぎになったため、各所の対応も早かったかと思います。そこで、比較的Log4Shellの影響が落ち着いてき
Java向けログ出力ライブラリ「Apache Log4j」(Log4j)で12月10日に判明した脆弱性を巡り、中国の行政機関である中国工業情報化部はこのほど、提携関係にあるアリクラウド(阿里雲)が脆弱性情報を発見後すぐに報告しなかったとして6カ月間の提携停止処分とした。中国の報道機関・21世紀経済報道が23日報じた。 問題となっているLog4jの脆弱性は、アリクラウドが発見したとされている。中国工業情報化部・ネットワーク安全管理局は、同社がこの脆弱性を米Apache Software Foundation(ASF)に報告した一方で、同局にはすぐに報告しなかったとしている。同局は別の情報セキュリティ機関からこの脆弱性の報告を受け、ASFに修正を促したという。 中国は「ネットワーク安全法」の第25条で「ネットワーク事業者は脆弱性など情報セキュリティ上のリスクが発生した場合、緊急対応を直ちに開始
はじめに 2021年12月に発見されたLog4jのCVE-2021-44228は、稀に見るレベル、まさに超弩級の脆弱性となっています。今回、私はTwitterを主な足がかりとして情報収集を行いましたが、(英語・日本語どちらにおいても)かなりWAFそのものが話題になっていることに驚きました。ある人は「WAFが早速対応してくれたから安心だ!」と叫び、別の人は「WAFを回避できる難読化の方法が見つかった。WAFは役に立たない!」と主張する。さらにはGitHubに「WAFを回避できるペイロード(攻撃文字列)一覧」がアップロードされ、それについて「Scutumではこのパターンも止まりますか?」と問い合わせが来るなど、かなりWAFでの防御とその回避方法について注目が集まりました。 実はWAFにおいては、「回避(EvasionあるいはBypass)」との戦いは永遠のテーマです。これは今回Log4jの件で
JPCERT-AT-2021-0050 JPCERT/CC 2021-12-11(新規) 2022-01-04(更新) I. 概要 更新: 2022年1月4日記載 現時点で不明な点もあることから、今後の動向次第で下記掲載内容を修正、更新する予定がありますので、関連情報への注視のほか、本注意喚起の更新内容も逐次ご確認ください。 次の更新を行いました。詳細は「III. 対策」を参照してください。 - Apache Log4jのバージョン2.17.1(Java 8以降のユーザー向け)、2.12.4(Java 7のユーザー向け)及び2.3.2(Java 6のユーザー向け)が公開されました JavaベースのオープンソースのロギングライブラリのApache Log4jには、任意のコード実行の脆弱性(CVE-2021-44228)があります。Apache Log4jが動作するサーバーにおいて、遠隔の第三
log4jとはJava用のloggingライブラリだ。loggingライブラリというのはログとして記録すべき文字列を受け取り、それをどこかに出力するものだ。文字列の中身を通常のloggingライブラリは気にしない。 log4jが通常のloggingライブラリと違うのは、文字列の中身を見て、一部の文字列を変数とみなして置換することだ。これはlog4jのドキュメントではlookupと呼ばれている。 Log4j – Log4j 2 Lookups 例えばプログラムを実行中のJava runtimeのバージョンをログに含めたい場合は、"Java Runtime: ${java:runtime}"などとすると、"Java Runtgime: Java(TM) SE Runtime Environment (build 1.7.0_67-b01) from Oracle Corporation"などの
最近、久しぶりにコードレビューをすることが増えたのですが、UnitTestのコードを見るとヒドイ部分が多く残念な気持ちになることもあります。 原因のひとつとして、プロダクトコードと違いテストの書き方をあまり書き方を明文化してなかったのが悪かったなと思い、とりあえず明文化してみました。 今回は、命名規則とかそのレベルまではいかず「ユニットテストかくあるべし」ってところまでをまとめます。正直、これ守ってくれたらあとは好みの世界もあるしね。 追記: テクニカルな部分も最低限ですがQiitaに記載しました。 qiita.com 追記: もうちょっと大上段の規約に関してもまとめてみました。 koduki.hatenablog.com 前提 ここではユニットテストを関数レベルのテストをJUnitのような自動テストツールで取り扱う場合に限定します。 また、Mavenでビルド時は常にテストを回すことを想定
技術推進室の浅井です。 技術的負い目とは、世に言う技術的負債のことです。 社内で技術的負債の定義、ことばの表現を考える中で、「『負債』は優れた比喩表現であるものの、第三者への返済義務がない点で会計上の負債とは異なり、言葉としての問題も多く、不必要な議論を生み出しやすい」などの指摘があり、代わりの表現として社内の一部で使われている言い回しです。 最近社内のたいへん古いシステム(16年の歴史があります)の技術推進を行う機会があり、たくさんの技術的負い目と向き合いました。 そのような古いシステムの技術的負い目と向き合ったとき、エンジニアはストレスを感じ、ネガティブな感情を抱いてしまいがちです。負い目に苦しめられることで過去のコードや技術的判断に対して不満を言いたくなる気持ちはとてもよくわかりますし、実際に私もたくさん苦しんでたくさん不満を言いました。 ですが技術的負債の文脈でよく言われるとおり、
モバイルファースト室の @rejasupotaro です。 クックパッドでは、サービスをリリースしてログを収集して分析して改善してまたリリースして、というサイクルを素早く回すことでより良いものを作るということをウェブではやってきました。 クックパッドのサービス開発のフレームワークをモバイルアプリでも適用したいのですが、モバイルアプリにはウェブアプリと違ったロギングの難しさがあります。 今回はモバイルアプリのロギングの問題点とPureeというログ収集ライブラリについて話します。 モバイルアプリのロギングの難しさ ウェブアプリでは、基本的にはサーバー側でログを収集することができますが、モバイルアプリの場合は画面の制御はアプリ側で行われ、APIを介してデータを受け取るため、クライアント側でログを収集して送信する必要があります。 アプリのログを収集するのに、画面遷移をしたりタップするたびにサーバー
このページでは、大体 使い方(1,2)でやったのに準じて、Logback の使い方を解説する。 目次 Logback の呼び方、というか slf4j 解説 slf4jのロガー実装切替えメカニズム logback.xml ログ出力 レイアウト Logback の呼び方、というか slf4j 解説 まあ、抽象論よりも、具体的なコードを見ようじゃないか。サンプルコードはこんなものだ。 import org.slf4j.Logger; import org.slf4j.LoggerFactory; public class Test { protected static Logger log = LoggerFactory.getLogger( TestLogback.class ); public static void main( String [] args ) { new SimpleTe
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く