パスワードの1文字目に「~(チルダ)」を使って痛い目にあった - Qiita
何を言っているんだと思われるかもしれないですが、気軽にパスワードの1文字目に「~」を使わないほうがいいというお話です。 起こった問題 踏み台サーバー経由でサーバーAに接続して作業をしていた時の話です。 いわゆる多段 ssh 接続というもので、リモートワークになってからは結構使われる方も多いかと思います。 サーバーA上で root 権限になろうと sudo su - してパスワードを入力したら Connection to xxx.xxx.yyy.zzz closed. の文字とともにサーバーAから追い出されてしまいました。 なにかの間違いだろうと何度か挑戦していたのですが、結果はサーバーAから切断され踏み台サーバーに戻る羽目に。。。 そのときに入力していたパスワードが ~.xxxxxxxxxx のような ~ から始まるものでした。 調査 ~ って何か意味があったよなーと思ってどう調べようかと
文字コードの脆弱性はこの3年間でどの程度対策されたか?
4. デモ1:半端な先行バイトによるXSS • 半端な先行バイトとは – Shift_JIS、EUC-JP、UTF-8などマルチバイト文字の1 バイト目だけが独立して存在する状態 – 次の文字が、マルチバイト文字の2バイト目以降の文 字として「食われる」状況になる – input要素などの引用符「”」を食わせて、イベントハ ンドラを注入する攻撃 Copyright © 2010-2014 HASH Consulting Corp. 4 5. デモ１：PHPソース <?php session_start(); header('Content-Type: text/html; charset=Shift_JIS'); $p1 = @$_GET['p1']; $p2 = @$_GET['p2']; ?> <body> <form> PHP Version:<?php echo htmlspeci
「LINEウイルス」の正体とは―LINE内で流行する「ウイルス攻撃」の現状について
LINE周りで「ウイルスを送るぞ」という表現をよく見かけます。そして、「LINEにもウイルスがあるの？」と疑問に思ったり不安に思っている人も多数発生しています。今回は、LINEで広まりつつある「LINEウイルス」の正体と、「LINEウイルス」と呼ばれるものを使った攻撃の実態について紹介します。 @NAVER_LINE LINEのグループでウイルス送りつけるって言われたんですが送れるんですか？— yoshiaki (@yoshiak48538031) August 27, 2013 LINEでなんかウイルスを送り込む輩がいるって聞いたけど、ほんとなの？— Torm@サブアカ (@torm1998) August 23, 2013 LINEで言われている「ウイルス」について気になっている人は多いようです。 目次 1. 「LINEウイルス」の特徴2. 「LINEウイルス」に関するTweet2.1
エフセキュアブログ : RLOのトリックを使ったMacの署名済みマルウェア
RLOのトリックを使ったMacの署名済みマルウェア 2013年07月15日19:48 ツイート fsecure_corporation クアラルンプール発 by：ブロデリック・アキリノ RLO（Right-to-left override）とは、双方向のテキストエンコードシステムで使われる特殊文字で、テキストを右から左への表示に切り替える場所を指示するものだ。実行可能ファイルの本当の拡張子を隠蔽する目的で、昨年来Bredolabや高度なトロイの木馬MahdiといったWindowsマルウェアで一般的に使われている。トリックの詳細については、Krebs on Securityのこの投稿を確認してほしい。 我々はあるMac用のマルウェアがRLOのトリックを用いていることに気付いた。そして先週の金曜日にVirusTotalに投稿した。 ここでの目的は、Krebの投稿で触れられていたものほど複雑で
第9回 文字コードが引き起こす表示上の問題点［前編］ | gihyo.jp
文字コードが引き起こす問題点は、これまで説明したような比較の一致・不一致といったソフトウェアの処理上のものだけでなく、人間に対する視覚的な効果という点でも強く影響を与え、攻撃者にとっての強力な道具となることがあります。 今回および次回で、そのような文字コードが引き起こす視覚的な問題点を紹介します。 視覚的に似た文字 見かけのよく似た文字は、フィッシングなどによく利用されます。典型的な例としては、アルファベット小文字のl（エル）と数字の1などがあります。たとえば、http://bank1.example.jp/ というURLのオンラインバンクがあったとすると、攻撃者は http://bankl.example.jp/ というURLを使ってフィッシングを企むということは容易に想像できると思います。 もちろん、収録している文字数が増えれば増えるだけ、このように見かけのよく似た文字が存在する率も高
htmlspecialcharsに関する残念なお知らせ - 岩本隆史の日記帳（アーカイブ）
「htmlspecialcharsのパッチ私案」に書いた件、バグレポートを出してみましたが、「すでに同じバグレポートがあるだろ」という理由により、あえなく却下されました。 せめて先方が「同じ」とみなしているレポート番号ぐらいは示してほしくて、そのようにコメントしましたが、お相手のjaniという人は気難し屋のようで*1、教えてもらえる気がしません。 私なりに探した結果、下記のレポートがくさいように感じました。 PHP :: Bug #43896 :: htmlspecialchars() returns empty string on invalid unicode sequence 「不正なUTF-8シーケンスの場合に空文字列を返すのはおかしい」というレポートで、私のそれとは正反対どころか、Shift_JISにもEUC-JPにも触れられていない別個のものです。もちろん、私はレポート送信前に
何故かあたり前にならない文字エンコーディングバリデーション
(Last Updated On: 2018年8月8日)私が4年前（2005年）に「Webアプリセキュリティ対策入門」を執筆していた時には、既に壊れた文字エンコーディングなどの不正な文字エンコーディングを利用したJavaScriptインジェクションやSQLインジェクション攻撃は比較的広く知られていました。この問題は当時のスラッシュドットジャパンでも取り上げられていました。/.で取り上げられたので、そこら中のWebサイトとユーザが被害に合うのでは？とヒヤヒヤしたので良く覚えています。 不正な文字エンコーディングを利用した攻撃は、文字エンコーディングを厳格に取り扱い、文字エンコーディングをバリデーションすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減に文字エンコーディングを取り扱うと安全なシステムは作れないのです。 参考：エンジニア向けに
第7回 Unicodeからの多対一の変換［前編］ | gihyo.jp
文字コードが引き起こすセキュリティ上の問題として、もっとも興味深いもののひとつである、Unicodeから他の文字コードへの「多対一の変換」で引き起こされる問題点について、今回と次回で説明します。 ご存じのとおり、Unicodeには非常に多数の文字が収録されていますが（現在最新版のUnicode 5.1.0では100,713文字が収録されているそうです）、Unicodeから他の文字コードへの変換においては、互換性や可読性の維持のためか、複数のUnicodeの文字が他の文字コードでは単一の文字に変換されることがあります。 この「多対一」の変換が、開発者も想定していなかったような問題を引き起こす原因となることが多々あります。 具体的な例として、Windows上でのUnicodeからの変換について説明します。 Windows上でのUnicodeからShift_JISへの変換 Windows上で
第12回■主要言語別：入力値検証の具体例
これまで2回にわたってWebアプリケーションにおける入力値検証とセキュリティ対策の関係を説明してきた。入力値検証はセキュリティ上の根本的対策ではないが，保険的な対策として効果が期待でき，特に制御コードや不正な文字エンコーディングによる攻撃対策には有効であることを説明した。 今回は，Webアプリケーション開発によく使われる4種類の言語（Perl，PHP，Java，ASP.NET）に関して，入力時処理の具体例を示す。ここで取り上げる「入力時処理」とは以下の内容を含んでいる。 文字エンコーディングの検証文字エンコーディングの変換入力値検証 Perlによる実装の方針 Perl言語はバージョン5.8から内部文字エンコーディングとしてUTF-8をサポートし，文字単位での日本語処理が可能だ。文字エンコーディング処理にはEncodeモジュールを使用する。入力値検証には正規表現を用いるのが便利だ。 ■文字エ
第11回■制御文字や不正な文字エンコーディングによるぜい弱性を知ろう
前回，入力値検証をセキュリティ対策として実施すべき理由を説明する中で制御文字や不正な文字エンコーディングの問題を指摘した。今回は，その具体例として「ヌルバイト攻撃」と「冗長なUTF-8によるディレクトリ・トラバーサル」を説明する。 制御文字悪用の代表格「ヌルバイト攻撃」 ヌルバイト攻撃とは，ASCIIコード0の文字（ヌル文字）を用いた攻撃である。リスト1に示すPHPスクリプトは，クエリー文字列pとして数値を受け取り，それを表示するというもの。結果を表示する前に正規表現関数eregを使って数字だけのデータかどうかをチェックし，数字でない場合にはエラーメッセージを表示するようになっている。通常，数字だけを使った攻撃は不可能であり，このような「安全な文字」だけを許可するような検査方法を一般に「ホワイトリスト検査」と呼ぶ。
第5回 不正なバイト列の埋め込み | gihyo.jp
今回は、「不正なバイト列の埋め込み」という攻撃方法について紹介します。 文字列を入力とするソフトウェアにはさまざまなものがありますが、それらの処理系によっては、入力として与えた文字列中に、その文字コード上は不正となるようなバイト列を埋め込んでいたときに、それらのバイト列が無視されたり、想定外の文字に変換されてしまうことがあります。 たとえば、とあるソフトウェアにて （1) 処理A ＝ 文字列中に特定の文字（あるいは文字列）が含まれていないか検査 （2) 処理B ＝ 処理Aから受け取ったデータを処理。その際に不正なバイト列が無視あるいは別の文字に変換される という流れになっていた場合、後続の処理にて本来はフィルタリングされるべき文字列が含まれてしまうことになります。 このような流れを引き起こす具体的な例をいくつか紹介します。 Mozilla Firefoxにおける0x80の無視 Mozil
第4回 UTF-8の冗長なエンコード | gihyo.jp
今回は、文字コードに関連するセキュリティの話題では古参ともいえるUTF-8の冗長なエンコードというテーマについて紹介します。 UTF-8とは UTF-8は、各文字を1～4バイトの可変長で表現するUnicodeの符号化方式のひとつです。 U＋0000からU＋007Fの範囲の文字を0x00から0x7Fの1バイトで表現しているため、US-ASCIIと互換性がある、バイト列の途中からでも文字の先頭バイトを簡単に検出できる、多バイト文字の途中に0x00や0x5C（\）、0x2F（/）などが現れない、などの特徴があります。 UTF-8での文字のビットパターンは表1のようになります。 表1 UTF-8でのビットパターン
第9回■上流工程で文字集合仕様と文字エンコーディングを決定する
これらの対策のうち，ここでは「文字集合の変換を伴う変換をしない」など，アプリケーション全体の文字コードの取り扱いについて上流工程で留意すべき内容について説明しよう。「入力値のチェック」については次回以降，「入力値の検証」の項で詳しく説明する。「アプリケーションでの正しいマルチバイト文字の処理」については，個別の処理内容の項で説明する。 文字コードの取り扱いについて，上流工程で留意すべき点としては，次の三つが挙げられる。 要求仕様として文字集合を定義する端末がサポートする文字集合を確認する実装に用いる文字エンコーディングを決定する まずアプリケーション仕様として，処理対象となる文字集合を規定する必要がある。日英語以外の韓国語や中国語，アラビア語などの対応が必要な場合はUnicodeを選択するしかない。さらに日本語だけの場合でも，例えばJIS X 0201＋JIS X 0208はJIS第2水準
第7回■文字エンコーディングが生み出すぜい弱性を知る
文字コードに関する問題は大別すると文字集合の問題と文字エンコーディングの問題に分類できる。前回は文字集合の取り扱いに起因するぜい弱性について説明したので、今回は文字エンコーディングに起因するぜい弱性について説明しよう。 文字エンコーディングに依存する問題をさらに分類すると2種類ある。（1）文字エンコーディングとして不正なデータを用いると攻撃が成立してしまう点と，（2）文字エンコーディングの処理が不十分なためにぜい弱性が生じることがある点だ。 不正な文字エンコーディング（1）――冗長なUTF-8符号化問題 まず，（1）の不正な文字エンコーディングの代表として，冗長なUTF-8符号化問題から説明しよう。前々回に解説したUTF-8のビット・パターン（表1に再掲）を見ると，コード・ポイントの範囲ごとにビット・パターンが割り当てられているが，ビット・パターン上は，より多くのバイト数を使っても同じコー
第8回■主要言語の文字エンコーディングの対応状況を押さえる
文字コードの問題に正しく対応する前提として，アプリケーションが稼働する基盤ソフトウエアがマルチバイト文字列処理に対応している必要がある。特に問題となるのが，言語処理系とデータベース管理システム（DBMS）である。利用者の使い方が正しくない場合も，ぜい弱性が混入することがある。このため，今回は主要言語とデータベース（MySQLとMS SQL Server）のマルチバイト文字対応状況について説明する。 文字列の処理単位は文字単位かバイト単位か Webアプリケーション開発で人気のあるスクリプト言語の多くは，かつては文字列をバイト単位で扱っているものが多かった。以下のPerlスクリプトは“漢字”という文字列の長さを表示するものだが，ソースの文字エンコーディングによって結果が変わる。具体的には，Shift_JISやEUC-JPの場合は4，UTF-8の場合は6と表示される。原因は，このスクリプトが文字
第6回■異なる文字集合への変換がぜい弱性につながる
文字集合自体は抽象的な「文字の集まり」に過ぎないので単独で問題になることはないが，異なる文字集合に変換する際には問題が発生する場合がある。文字集合が異なるということは，対応する文字が1対1対応していないので，変換先の文字集合で対応する文字がないケースや，多対1の対応が発生する可能性がある。 図1に，Unicodeからマイクロソフト標準キャラクタセットに変換する場合を例示した。マイクロソフト標準キャラクタセットには「骶」（尾てい骨の“てい”）や，ハングルなどはない。また，バックスラッシュ「\」（U+005C）と円記号「\」（U+00A5）がともにJIS X 0201の「\」（0x5C）に変換される場合について示している。 「漢」のように1対1対応している文字は問題ない。ハングルや「骶」のように対応するコードポイントがない場合はエラーになるか文字化けする。インターネットで「尾 骨 びていこつ」
第5回■注目される文字コードのセキュリティ問題
今回から5回にわたって，アプリケーション全体に関する文字コードの問題と対策について説明する。文字コードがセキュリティとどう関わるのか，疑問に思うかもしれないが，Webアプリケーションで文字コードを指定可能な個所は非常に多く，しかも文字コードの選定や処理方法次第ではぜい弱性の原因になることが分かってきている（図1）。実は文字コードはWebアプリケーションのセキュリティ問題の最新の話題と言ってよい。 2008年10月に開催されたセキュリティ・イベントBlack Hat Japan 2008では，ネットエージェントの長谷川陽介氏が「趣味と実益の文字コード攻撃」と題して，文字コード問題の広範なプレゼンテーションを発表した 。そのプレゼンテーション資料が発表されている のでこの問題の詳細に関心のある方は参照されたい。ここでは，セキュアなWebアプリケーションを開発するために文字コードの問題をどのよう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
