「世界最悪のログイン処理コード」を解説してみた
概要 ところでこのツイートを見てほしい。このソースコードをどう思う？ 世界最悪のログイン処理コード。 実際のサービスで可動していたものだとか……https://t.co/C2bG93ZCkj pic.twitter.com/EfVNAEslrn — はっしー@海外プログラマ🇳🇿元社畜 (@hassy_nz) 2018年8月10日 すごく……セキュリティーホールです…… 一応は動いていますが、あまりに問題がありすぎるため、Twitterでも話題になっていました。 問題点は片手に入り切らないぐらいある気がしますが、一つづつ解説していきます。 ※元記事のタイトルに記載されていますが、このコードはイントラネット内で動作していたものです。 問題点リスト 1. クライアント上のJavaScriptで書かれている 他の問題点を全部ぶっ飛ばすぐらいの重大な不具合です。 クライアントと言うのはこの場合、
知っておくべきITセキュリティ概念Top 10 〜ショート版〜
(Last Updated On: 2018年8月16日)ITシステム開発者必修のセキュリティ概念 Top 10です。ここで紹介する概念はセキュリティ設計やセキュアコーディングを行う上で欠かせないモノばかりです。順序はその基礎知識性、重要性、分かり易さで付けています。 では開発者必修のセキュリティ概念 Top 10です。 ※ 長くなったので短い版を作りました。ロング版はこちら 1. ゼロトラスト ゼロトラスト（Zero Trust）とは何も信頼しないことです。言い換えると、検証／保証したモノ以外は信頼しない、です。セキュリティはコアとなる信頼できるモノから、リスクの検証／許容で信頼可能な範囲を広げていきます。 2. 信頼境界線 信頼境界線（Trust Boundary）は信頼可能な範囲の境界です。”ゼロトラスト”で信頼できる範囲を広げても、様々な制約から必ず「ここが限界」という境界ができま
CGI版PHPにリモートからスクリプト実行を許す脆弱性(CVE-2012-1823)
CGI環境でPHPを動作させているサイトには、リモートからスクリプト実行を許してしまう脆弱性があります。php.netから提供されている修正リリース(PHP 5.3.12 / PHP 5.4.2)は不完全なため、該当するサイトは至急回避策を導入することを推奨します。 概要 CGIの仕様として、クエリ文字列に等号を含めない場合は、クエリ文字列がCGIスクリプトのコマンドライン引数として指定されます。 例えば、http://example.jp/test.cgi?foo+bar+bazという呼び出しに対しては、test.cgiは以下のコマンドラインで呼び出されます。 test.cgi foo bar baz この仕様を悪用して、CGI版のPHPにコマンドライン引数としてPHPのオプションを指定できます。例えば、http://example.jp/test.php?-s というリクエストは、-s
そらいさんのサイトが改竄されたそうなので解析してみた
そらいさんのサービスが改ざん被害にあったとのことで、攻撃コードが載っていたので解析して見ました。 ということで、上記のコードを解析しましたが、難読化の仕組みは単純なのですが、コードを追いかけるのに中々疲れましたｗｗ 問題のコード問題のコードはこれです。 <?php @error_reporting(0); if (!isset($eva1fYlbakBcVSir)) { $eva1fYlbakBcVSir = "7kyJ7kSKioDTWVWeRB3TiciL1UjcmRiLn4SKiAETs90cuZlTz5mROtHWHdWfRt0ZupmVRNTU2Y2MVZkT8h1Rn1XULdmbqxGU7h1Rn1XULdmbqZVUzElNmNTVGxEeNt1ZzkFcmJyJuUTNyZGJuciLxk2cwRCLiICKuVHdlJHJn4SNykmckRiLnsTKn4iInIiL
今日こそわかる、安全なWebアプリの作り方2010
Internet Week 2010 S3 今日こそわかる、安全なWebアプリの作り方2010 http://www.nic.ad.jp/iw2010/program/s3/
PHP5.3.7のcrypt関数のバグはこうして生まれた
昨日のブログエントリ「PHP5.3.7のcrypt関数に致命的な脆弱性(Bug #55439)」にて、crypt関数の重大な脆弱性について報告しました。脆弱性の出方が近年まれに見るほどのものだったので、twitterやブクマなどを見ても、「どうしてこうなった」という疑問を多数目にしました。 そこで、このエントリでは、この脆弱性がどのように混入したのかを追ってみたいと思います。 PHPのレポジトリのログや公開されているソースの状況から、PHP5.3.7RC4までこのバグはなく、PHP5.3.7RC5でこのバグが混入した模様です。RC5はPHP5.3.7最後のRelease Candidateですから、まさに正式リリースの直前でバグが入ったことになります。 バグの入る直前のソースは、ここの関数php_md5_crypt_rから参照することができます。以下に、おおまかな流れを図示します。まずはバ
今夜こそわかる安全なSQLの呼び出し方 ～ 高木浩光氏に聞いてみた
「安全なSQLの呼び出し方」というSQLのセキュリティに焦点を当てたドキュメントが、2010年3月にIPA（独立行政法人情報処理推進機構）から公開された。 これは2006年1月から提供されている、Webサイト開発者や運営者向けのセキュアWebサイト構築のための資料「安全なウェブサイトの作り方」の別冊として書かれたものである。「安全なウェブサイトの作り方」が92ページなのに対して、SQLインジェクションについてだけで40ページもの分量がある。なぜこんなに分厚いのだろうか。 このドキュメント作成に協力したという、独立行政法人産業技術総合研究所 情報セキュリティ研究センターの高木浩光氏にお話を伺うことができた。高木氏は個人ブログ「高木浩光＠自宅の日記」で、セキュリティ関連の問題を追求する論客としても知られている。筆者も以前、この連載の「今夜わかるSQLインジェクション対策」の回（2006年11月
Webプログラミングにおいて、すべての言語はセキュアでない | スラド デベロッパー
しばしば、「○○というプログラミング言語は△△に比べて安全だ」「Webプログラミングの分野において最も安全な言語は何？」といった主張が繰り広げられることがある。これに対しSecurity Ninjaが「どの言語を選択しても関係ない、（なぜなら）それらは等しくセキュアでないからだ！」と反論している。 記事ではWhite Hat Securtyの統計レポート を元に、「どの言語も脆弱性がある入力の割合は大差なし」「かつて重要な脆弱性があったWebサイトの割合はどの言語でも70～80％台」「現在でも脆弱性があるWebサイトの割合はどの言語でも50～70％台」といったデータが示されている。このデータではPerlで実装されたWebサイトについて若干脆弱性が多いように見えるものの、結論としては「どの言語も等しくセキュアでない」とのことで、「セキュアなコードはセキュアな開発プロセスや開発者に対するセキュ
XSS (Cross Site Scripting) Cheat Sheet
XSS (Cross Site Scripting) Cheat Sheet Esp: for filter evasion By RSnake Note from the author: XSS is Cross Site Scripting. If you don't know how XSS (Cross Site Scripting) works, this page probably won't help you. This page is for people who already understand the basics of XSS attacks but want a deep understanding of the nuances regarding filter evasion. This page will also not show you how to
高木浩光＠自宅の日記 - ユニークIDがあれば認証ができるという幻想
■ ユニークIDがあれば認証ができるという幻想 2008年のNTTドコモによるiモードID送信開始以降、ケータイWebの世界に「かんたんログイン」なるエセ認証方式が急速に広がり、その実態は「はてなのかんたんログインがオッピロゲだった件」のように惨憺たるものになっている。こうした欠陥サイトはかなりあると考えられ、すべてを調べて廻ることはできないが、いくつかのメジャーどころのサイトについては、IPAの脆弱性届出窓口に通報して、対策を促す作業をやっている。 各サイトの「かんたんログイン」に欠陥があるかどうかは、実際に他人のIDでなりすましログインしてテストすることは許されない（不正アクセス禁止法違反になる）ので、自分用のアカウントを作成して（会員登録して）、自分のIDについてテストするのであるが、誰でも会員登録できるわけでないサイトがかなりあるようで、そういったサイトはどうしたらよいのか。以下は
PHP と Web アプリケーションのセキュリティについてのメモ
このページについての説明・注意など PHP は、Apache モジュールや、CGI、コマンドラインとして使用できるスクリプト言語です。このページでは、主に PHP における、Web アプリケーションのセキュリティ問題についてまとめています。 Web アプリケーションのセキュリティ問題としては、以下の問題についてよく取り挙げられていると思いますが、これらのセキュリティ問題について調べたことや、これら以外でも、PHP に関連しているセキュリティ問題について知っていることについてメモしておきます。 クロスサイトスクリプティング SQL インジェクション パス・トラバーサル(ディレクトリ・トラバーサル) セッションハイジャック コマンドインジェクション また、PHP マニュアル : セキュリティや、PHP Security Guide (PHP Security Consortium) には、PH
PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14)
_既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト（言語、フレームワークなど）か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ
UTF-8の冗長なエンコードとは何で、なんでそれがセキュリティ的に危ないのか？を文字コード知識レヴェル3くらいの凡プログラマが考えてみる - tohokuaikiのチラシの裏
何故かあたり前にならない文字エンコーディングバリデーション | yohgaki's blog ってあるように、いまいち文字コードの不正な判定による危険性ってのが分かってない。 SJISの問題は、（2/3）SQLインジェクションを根絶！セキュア開発の極意 - 第5回■注目される文字コードのセキュリティ問題：ITproの記事がわかりやすかった。 というか、やっぱりPHP使ってると誰でも一度は「なんじゃこの『￥』は？」って思うもんなんで。 なるほど、確かに↓の図のように「あるバイト」が2つの意味を持つっていう文字コード形態はやばいんだなと。 EUC-JPはそんなことはしないで、1つのバイトには1つの意味しか取らせない。 だけど、これでも文字化けが起こることがある。経験的には、「マルチバイトをXX文字で切り落としたい」とかやった場合。ちゃんと文字コードを判定してくれるPHPでいえばmb_subst
Webアプリにおける11の脆弱性の常識と対策
Webアプリにおける11の脆弱性の常識と対策：Webアプリの常識をJSPとStrutsで身につける（11）（1/4 ページ） 本連載は、JSP／サーブレット＋StrutsのWebアプリケーション開発を通じて、Java言語以外（PHPやASP.NET、Ruby on Railsなど）の開発にも通用するWebアプリケーション全般の広い知識・常識を身に付けるための連載です 【2013年2月25日】編集部より、おわびと訂正のお知らせ 本稿において読者の皆さまより多数のご指摘をいただきまして、誠にありがとうございます。編集部であらためて調べた結果、間違いを把握し、あらためて修正版を掲載させていただきます。この度は、長期にわたり誤った内容を掲載したので、読者の皆さまに多大なご迷惑をお掛けしたした点をおわび申し上げます。 通常、記事に間違いがあった場合には、筆者確認後に修正版を掲載するのですが、今回の場
連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説（前編）
第7回■文字エンコーディングが生み出すぜい弱性を知る
文字コードに関する問題は大別すると文字集合の問題と文字エンコーディングの問題に分類できる。前回は文字集合の取り扱いに起因するぜい弱性について説明したので、今回は文字エンコーディングに起因するぜい弱性について説明しよう。 文字エンコーディングに依存する問題をさらに分類すると2種類ある。（1）文字エンコーディングとして不正なデータを用いると攻撃が成立してしまう点と，（2）文字エンコーディングの処理が不十分なためにぜい弱性が生じることがある点だ。 不正な文字エンコーディング（1）――冗長なUTF-8符号化問題 まず，（1）の不正な文字エンコーディングの代表として，冗長なUTF-8符号化問題から説明しよう。前々回に解説したUTF-8のビット・パターン（表1に再掲）を見ると，コード・ポイントの範囲ごとにビット・パターンが割り当てられているが，ビット・パターン上は，より多くのバイト数を使っても同じコー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
徳丸本に載っていないWebアプリケーションセキュリティ
PHPでセキュリティを真面目に考える
