Log4jで話題になったWAFの回避/難読化とは何か
はじめに 2021年12月に発見されたLog4jのCVE-2021-44228は、稀に見るレベル、まさに超弩級の脆弱性となっています。今回、私はTwitterを主な足がかりとして情報収集を行いましたが、(英語・日本語どちらにおいても)かなりWAFそのものが話題になっていることに驚きました。ある人は「WAFが早速対応してくれたから安心だ！」と叫び、別の人は「WAFを回避できる難読化の方法が見つかった。WAFは役に立たない！」と主張する。さらにはGitHubに「WAFを回避できるペイロード(攻撃文字列)一覧」がアップロードされ、それについて「Scutumではこのパターンも止まりますか？」と問い合わせが来るなど、かなりWAFでの防御とその回避方法について注目が集まりました。 実はWAFにおいては、「回避(EvasionあるいはBypass)」との戦いは永遠のテーマです。これは今回Log4jの件で
脆弱性を抱えるソフトウェア開発キット「Moplus」、実はバックドア機能の実装が判明 | トレンドマイクロ セキュリティブログ
中国の検索エンジン「百度（Baidu）」のソフトウェア開発キット（Software Develoment Kit、SDK）「Moplus」に「Wormhole」と呼ばれる脆弱性が確認され、この脆弱性が利用された場合の影響の深刻さゆえに波紋を呼んでいます。この脆弱性は、中国の脆弱性報告プラットホーム「WooYun.og」により確認されました。 しかしながら、トレンドマイクロがこの脆弱性について調査を進めたところ、Moplus SDK 自体にバックドア機能が備わっており、必ずしもそれが脆弱性に由来または関連しているわけではないことが明らかになりました。現時点で、この問題は Moplus SDK のアクセス許可制御とアクセスの制限方法にあると見られています。そのため、脆弱性が関係していると考えられているのですが、実際には、この SDK のバックドア機能により、ユーザ権限なしに以下を実行する恐れが
通信系のデバッグには Charles が便利 - Qiita
はじめに Charles を使うと PC 上に HTTP プロキシを立てて端末の通信をキャプチャし、リクエストやレスポンスの内容を覗いたり書き換えることが出来る。類似のソフトウェアとして Wireshark や Fiddler, Paros がある。 アプリの開発をしていてよくあるのは、APIがスタブで固定値しか返してくれない、異常系エラーのデバッグがやりづらい、という場面だが、Charles なら通信を好きに値を書き換えられるのでこれらに簡単に対処することができる。 Charles は Java アプリなので OS X だけでなく Windows や Linux でも利用する事が出来る。本稿では OS X + iOS での利用を前提として Charles の導入から簡単な使い方までを説明するが、環境依存の箇所は適宜読み替えてほしい。 導入 本来は有料ライセンスだが、無料でも数分間だけ使用
Webシステムにおけるデータベース接続アーキテクチャ概論 - ゆううきブログ
先月投稿した2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介しました。 今回は、前回同様、主に新卒Webエンジニア向けに、Webアプリケーションサーバとデータベースサーバ間の接続管理モデルと運用事情について紹介します。 データベース接続の永続化やコネクションプーリングとは何なのか、なぜ必要なのかといったことが主な話題です。 背景 データベース接続の永続化とはなにか データベース接続のオーバヘッド データベース接続の永続化手法 コネクションプーリングとはなにか コネクションプーリング: ドライバ型 コネクションプーリング: プロキシ型 コネクションプーリング全体について PostgreSQLとMySQL 参考資料 まとめ 背景 2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャの話とWebアプリケーショ
AndroidのHttpURLConnection。 - なるようになるかも
これはAndroidじゃなくてJDKのインターフェースの設計の問題なのですが、HttpURLConnectionは入出力エラーが発生した際にIOExceptionを投げるという規定があります。 問題は、HTTPステータスコードが400番台ないし500番台のコードのボディを読もうとした際に、getInputStream()を使うと入出力エラー扱いされてIOExceptionが発生することです。 最近のRESTfulなサーバーインターフェースの設計だと、HTTPステータスコードに意味を持たつつ、レスポンスボディにコンテンツを渡すのが主流ですが、HttpURLConnectionのちょっとしたサンプルでは400 Bad Requestや401 Unauthrizedが返されることを考慮していないことが多いです。 HttpURLConnectionを本格的に使おうとすると、大抵ここで躓くことになり
Androidの通信処理に何使えばいいのか分からないって話。 - なるようになるかも
特に結論はないです。本当に分からないので。 ソケットレベルまで踏み込むと、途端に面倒になってどのライブラリを使っても手に負えませんし、単にGETとかPOSTとかする分には正直どれ使ってもそこまで変わらない気がしてます。 それより自己署名証明書の検証を無視して通信を行うと端末が爆発するライブラリが必要だと思います。 Apache HTTP Client みんなお馴染みDefaultHttpClient。色々なライブラリがあるけど、最終的にはここに行き着いていることが多いです。 しかし「Apache HTTP Clientとは何なのか」、という説明はあまり見ない気がします。 自分も「Apacheソフトウェア財団のトップレベルプロジェクトとして運用されている、RFCを満たす実装を目指したJava向けのHTTPインターフェース」という超ふんわりとした認識しかないです。 かなり巨大なライブラリで、全
Java 9の新機能（予定）がオラクルから早くも発表に
今年の3月にJava 8が正式公開され、次のJava 9はおそらく2年後の2016年に登場すると予想されますが、そのJava 9に搭載される予定の新機能がオラクルから発表されたとInfoQの記事「Oracle Announces First Java 9 Features」が報じています。 InfoQが報じたJava 9の新機能は、JDK Enhancement Proposals（JEP）のインデックスページの中からバージョン9の予定になっているものとしても見つけられるようです。主なものをリストアップしました。 HTTP 2 Client HttpURLConnectionを置き換える予定で、HTTP 2.0とWebSocket対応 Light-Weight JSON API RFC7159に準拠したJSONデータの生成と読み込みを行うライトウェイトAPIを提供する Process AP
生存戦略そこが聞きたい - L'eclat des jours(2012-04-03)
_ 生存戦略そこが聞きたい secondlifeさんの『なぜ XXX がダメか』を読み、いろいろ去来するものがあるのだ。胸ではなく脳を。 特に、なぜMochiKitの選択で謝っているのかは知りたいところだ。進化が止まった点なのか、それとも別の問題なのか。前者なら、SI的な視点からは逆に安定性という意味で問題ない選択ということになるし（つまり、それはそれで参考になる選択であったわけだし）、後者ならそれはケーススタディとして知りたいところだ。 で、まあ過去10年以上、おれさまプロトコルかHTTPかとか、DCOMかおれおれXML-RPC over HTTPかとか、貴族なXMLとボヘミアンなXMLつまりDTDかWXSかRelax-NGか無手勝かとか、おれさまかStrutsかとか、おれさまかSpringかとか、ASP.NETのWebFormかMVCかとか、WFCかASMXかとか、XMLかJSONかと
Android組込みのHttpComponent（HttpClient）の正しい使い方といくつかのtips - terurouメモ
ブログ等に掲載されているHttpComponentのサンプルコードは、重要なところが端折られて紹介されている（というか間違っている事を知らずに書いている疑惑すらある）ことが多いので、正しいサンプルコードを書いておく。 まぁ、ここだけでなくApache HttpComponentsのドキュメントもちゃん読みましょう。あ、Androidのリファレンスにはロクに使い方が書いてないので、あんなゴミだけ読んでてもダメですよ。 要点 ポイントは2つ。 ResponseHandlerを使ってコードを書く HttpResponseの内部リソースを自動で解放してくれるので、ミスがなくなり、コードも簡潔になる。ブログ等ではHttpResponseを使わないコードもよく掲載されているが、リソースの解放処理が記述されていないことが多いのであまりよろしくない。 なお、ResponseHandlerを使わずに自分でリ
こてさきAjax:WebSocketがデフォルトdisableとなった件 - livedoor Blog（ブログ）
拙著（「徹底解説 HTML5 APIガイドブック コミュニケーション系API編」）の補足・修正POSTです。 p.24にWebSocketをサポートしているブラウザが記載されていますが、周知の通り、以下のブラウザでデフォルトdisableになりました。 FireFox4 Opera11 ちなみに、執筆以降サポートを開始した iOS4.2.1のsafari は、現状使える状態です。 disableとなった理由は、現状実装されているバージョン（Draft76）にセキュリティ上の脆弱性が見つかったため。脆弱性がFixされた仕様がIETFで固まれば、マイナーバージョンであっても再び対応するとのこと。 http://hacks.mozilla.org/2010/12/websockets-disabled-in-firefox-4/ 脆弱性の詳細は、Adamさんのレポートで述べられています。 ただし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JavaOne2015報告またはこれからのJava
GitHub - square/okhttp: Square’s meticulous HTTP client for the JVM, Android, and GraalVM.