タグ

securityに関するk1LoWのブックマーク (26)

  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • 地獄のJavaScriptセキュリティ

    TopicsPlaceHolder SectionTitlePlaceHolder TIME rest time current/total en

  • 「ニフティrクラウドユーザーブログ」は、移転しました。

    「ニフティクラウドユーザーブログ」は、移転しました。 自動でページを移動しない場合は、下記のリンクをクリックし、 新しい「ニフティクラウドユーザーブログ」をご覧ください。 今後とも「ニフティクラウドユーザーブログ」をよろしくお願いいたします。 > ニフティクラウドユーザーブログ

  • 実は厄介、ケータイWebのセッション管理

    実は厄介、ケータイWebのセッション管理:再考・ケータイWebのセキュリティ(3)(1/3 ページ) “特殊だ”と形容されることの多い日の携帯電話向けWebサイト。そこには、さまざまな思い込みや性善説の上しか成り立たないセキュリティが横行しています。連載は、ケータイWebの特殊性をていねいに解説し、正しいケータイWebセキュリティのあるべき姿を考えます(編集部) 「Cookieを使えない端末」でセッションを管理する方法は? 第2回「間違いだらけの『かんたんログイン』実装法」ですが、多くの方に読んでいただきありがとうございました。 今回は、前回に引き続き架空のSNSサイト「グダグダSNS」のケータイ対応を題材として、ケータイWebのセッション管理の問題点について説明します。携帯電話向けWebアプリケーション(ケータイWeb)のセッション管理は、かんたんログインよりも対策が難しく、厄介な問

    実は厄介、ケータイ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

  • 第39回 MOPS:静的PHPソースコード脆弱性スキャナ RIPS | gihyo.jp

    第32回 PHPセキュリティ月間(Month of PHP Sercurity)で「PHPセキュリティ月間」(⁠MOPS - Month of PHP Security)について簡単に紹介しました。 今回は静的にPHPソースコードを分析しセキュリティ脆弱性を検査するツールの紹介です。 MOPS Submission 09: RIPS - A static source code analyser for vulnerabilities in PHP scripts http://www.php-security.org/2010/05/24/mops-submission-09-rips-a-static-source-code-analyser-for-vulnerabilities-in-php-scripts/index.html 昨年発見された脆弱性のおよそ3割がPHPアプリケーシ

    第39回 MOPS:静的PHPソースコード脆弱性スキャナ RIPS | gihyo.jp
  • 文字コードに起因する脆弱性を防ぐ「やや安全な」php.ini設定

    補足 この記事は旧徳丸浩の日記からの転載です(元URL、アーカイブはてなブックマーク1、はてなブックマーク2)。 備忘のため転載いたしますが、この記事は2010年9月27日に公開されたもので、当時の徳丸の考えを示すものを、基的に内容を変更せずにそのまま転載するものです。 補足終わり PHPカンファレンス2010にて「文字コードに起因する脆弱性とその対策」というタイトルで喋らせていただきました。プレゼンテーション資料をPDF形式とslideshare.netで公開しています。 文字コードのセキュリティというと、ややこしいイメージが強くて、スピーカーの前夜祭でも「聴衆の半分は置いてきぼりになるかもね」みたいな話をしていたのですが、意外にも「分かりやすかった」等の好意的な反応をtwitter等でいただき、驚くと共に喜んでいます。土曜にPHPカンファレンスに来られるような方は意識が高いというの

  • Kazuho@Cybozu Labs: (Twitter の XSS 脆弱性に関連して) 構造化テキストの正しいエスケープ手法について

    昨日の Twitter の XSS 騒ぎは、まだ皆さんの記憶に新しいことと思います。いい機会なので、ツイートのような構造化テキストのエスケープ手法について触れておきたいと思います。 Twitter のメッセージは、単なる平文(プレインテキスト)ではなく、「@英数字」のような他のユーザーへの言及と「http://〜」のような URL を自動的にハイパーリンク化する構造化テキストです。 このような複数のルールをもつ構造化テキストを HTML 化する際には、どのようなコードを書けばいいのでしょう? まず「@〜」をリンク化してから、URL をリンク化すればいいのでしょうか? それだと、@〜 のをリンク化した A HREF タグの中の URL がさらにリンク化されていまいますね。 では、URL をリンク化してから @〜 をリンク化すればいいのでしょうか? それだと、@ を含む URL があった場合に

  • Kazuho@Cybozu Labs: String::Filter っていうモジュール書いた - 続: (Twitter の XSS 脆弱性に関連して) 構造化テキストの正しいエスケープ手法について

    先のエントリ「(Twitter の XSS 脆弱性に関連して) 構造化テキストの正しいエスケープ手法について」の続き。 弾さんが「404 Blog Not Found:DHTML - 構造化テキストは構造化するのがやっぱ正しい」で示されているような DOM ベースの操作を行えば、原理的に XSS 脆弱性を防ぐことができます。ただ、クライアントサイド JavaScript によるレンダリングはウェブの構造を破壊するという点で筋が悪い(テーブルと FONT タグを利用したページレイアウトが批判されていた頃を覚えていらっしゃいますでしょうか。JavaScript によるレンダリングはウェブのリンク構造も破壊するので一層たちが悪いというのが自分の考え)ですし、サーバサイドでの DOM 操作は重たいので、できれば避けたいところです。 構造化テキストの HTML への変換は、よほど複雑な記法でない限り

  • CakePHPの防御力を試す1〜SQLインジェクション〜 - すたら日記

    【CakePHP 1.3.2】 CakePHPのデフォルトの状態で、どこまでセキュリティ対策が 施されているのかを実験します。 【実験方法】デバッグを"2"に設定し、予想される攻撃によってどのような SQLが生成されるのかを確認します。 【/app/config/core.php】 Configure::write('debug', 2); 1. SQLインジェクション 【実験環境】下記の3つのメソッドについて、CakePHPの対応を見てみます。 read() find() findById() 【コントローラ】 function view($id){ //【1】 $this->data = $this->User->read(null, $id); //【2】 $this->data = $this->User->find('first', array('conditions'=>arr

    CakePHPの防御力を試す1〜SQLインジェクション〜 - すたら日記
  • 画像ファイルに PHP コードを埋め込む攻撃は既知の問題

    (Last Updated On: 2015年9月10日)国内外のメディアで「画像ファイルに攻撃用のPHPコードが含まれていた」と比較的大きく取り上げられています。しかし、この攻撃手法は古くから知られていた方法です。条件は多少厳しくなりますがPerl, Ruby, Pythonでも同様の攻撃は考えられます。PHPの場合は言語仕様的に他の言語に比べ攻撃が容易です。 典型的な攻撃のシナリオは次の通りです。 追記:Tokenizerを使った例に修正しました。 アバダなどの画像ファイルをアップロードできるサイトを探す ローカルファイルインクルードバグを探す 画像ファイルにサイトが利用している言語のコードを埋め込む 攻撃コードを含んだファイルを画像ファイルとしてアップロードする ローカルファイルインクルードバグを利用して攻撃コードを実行する PHPの場合、リモートインクルードバグを攻撃するための攻撃

    画像ファイルに PHP コードを埋め込む攻撃は既知の問題
  • Webアプリケーション向けの自動セキュリティスキャナ「Skipfish」を試してみました

    * GNU C Compiler * GNU Make * GNU C Library (including development headers) * zlib (including development headers) * OpenSSL (including development headers) * libidn (including development headers) KnownIssues – skipfish –参照。 私の環境では、libidnがなかったので、yumで入れました。 さて、skipffish体のインストールを行いましょう。 ※最新のダウンロードはこちらのページを参照ください。 http://code.google.com/p/skipfish/ # wget http://skipfish.googlecode.com/files/skipfi

    Webアプリケーション向けの自動セキュリティスキャナ「Skipfish」を試してみました
  • グーグル、Webアプリケーション脆弱性スキャナ「Skipfish」を公開 - @IT

    2010/03/23 米グーグルは3月19日、Webアプリケーションの脆弱性を検査するスキャナ「Skipfish」を公開した。Apache License 2.0の下、オープンソースソフトウェアとして無償で公開されている。 Skipfishは、Webアプリケーションの脆弱性を自動的に検出するツールだ。Nessusなど、ポートスキャンやバッファオーバーフローの有無などを検査するツールとは異なり、Webアプリケーションに特有のセキュリティホールを検査するもので、Webアプリケーションの開発者やサービス提供者向けに公開されている。 具体的には、SQLインジェクションやコマンドインジェクションといった、外部からの不正侵入の原因となりうるWebアプリケーションの脆弱性を検査し、レポートする。また、同じくグーグルがオープンソースで公開している、プロキシサーバ型の脆弱性検査ツール「Ratproxy」のロ

  • CakePHPのSecurityコンポーネントの機能を縮小してみた - モトクロスとプログラムと粉砕骨折と

    プログラミングのお時間です。 いまCakePHP使って色々と遊んでるんだけど、Amebaナウで話題になったCSRF対策に、Serucityコンポーネントを使ってみた。 ただこのコンポーネント、高機能すぎてちょっと使いづらい。 自分としてはToken使ったページ遷移チェックだけで良かったんだけど、ご丁寧にフォーム改ざんチェックとかもしてくれてる。もちろん普通に使う分には問題無いです。 だけどJavaScriptで動的にフォームを変更してたり、ちょっと変わった画面遷移してたりすると、途端にチェックに不合格になってしまう。 最初CakePHPの使い方がよく分からなくて、妙な画面遷移とアクションの組み合わせにしてしまったのは僕です。 だから軽量版のSecurityコンポーネントを作ってみた。 いや。作ってみたというと偉そうだ。正確にはSecurityComponentの機能をごっそり消して、Tok

  • 「わざと脆弱性を持たせたWebアプリ」で練習を

    命名・「やられWebアプリケーション」(仮) 構築したWebアプリケーションがセキュアかどうかを確かめる方法として、疑似的に攻撃を行うことで問題を発見する「脆弱性診断」があります。脆弱性診断は専門業者が実施することがほとんどだと思いますが、あなた自らが脆弱性診断の技術を身につけることで、セキュアWebアプリケーションについての理解が深まるとか、自社内で脆弱性診断ができるようになるといったこともあるかもしれません。 脆弱性診断の技術を身につける過程では、脆弱性を見つける手法を試したり、診断ツールを試したりする必要がありますが、診断といえど攻撃と同様のことを行うので、気軽に実稼働環境で実験するわけにもいきません。ましてや、他人や他社のWebサイトで試すなどはもってのほかです。 そこで、わざと脆弱性を持たせたWebアプリケーションと、それを動作させる環境が必要になります。 このような環境をわざわ

    「わざと脆弱性を持たせたWebアプリ」で練習を
  • PHPの設定をセキュリティの観点から改善·PHP Security Consortium MOONGIFT

    PHPは広く数多のWebサーバでインストールされ、使われている。設定ファイルは殆どそのままで使われていることが多いのではないだろうか。だが4.2より前のバージョンではregister_globalsのデフォルトがOnになっていたなど、利便性とセキュアであることとの関係で潜在的な問題はあるかも知れない。 php.iniのセキュリティチェックに 見直すのはPHPの設定ファイルであるphp.iniだが、多数の設定があるのでぱっと見では設定の善し悪しが分かりづらいかも知れない。そこで使うのがPHP Security Consortiumだ。 今回紹介するオープンソース・ソフトウェアはPHP Security Consortium、PHPセキュリティ設定を見直すソフトウェアだ。 PHP Security ConsortiumはPHPで作られたソフトウェアで、phpinfo()から得られる情報を使っ

    PHPの設定をセキュリティの観点から改善·PHP Security Consortium MOONGIFT
  • コメント masa (2008/02/29 18:31) - パスワードの定期変更は「神話」なのか? - ockeghem(徳丸浩)の日記

    ITProの記事が契機となって、PCIDSS(PCIデータセキュリティ規準)およびパスワードに関する規定が話題となっている*1。 「パスワードは90日ごとの変更」が義務づけられる!? | 日経 xTECH(クロステック) それに対して,PCIDSSは表現が具体的である。現在のバージョン1.1ではパスワードについて下記のような規定がある。 ■要件8.5.8 グループ、共有または汎用のアカウントとパスワードを使用しないこと。 ■要件8.5.9 ユーザー・パスワードは少なくとも90日ごとに変更する。 http://itpro.nikkeibp.co.jp/article/OPINION/20080220/294287/ このうち、要件8.5.9「ユーザー・パスワードは少なくとも90日ごとに変更する」に関して疑問を持った。これはいわゆる「セキュリティの常識」という奴の一つではあるが、実際のところ、

    コメント masa (2008/02/29 18:31) - パスワードの定期変更は「神話」なのか? - ockeghem(徳丸浩)の日記
  • » セキュアなサーバを作るために最低限やっておくこと: エスキュービズム ラボ Blog

    Recent Entries セキュアなサーバを作るために最低限やっておくこと Yahooキーワード抽出APIライブラリ テスト駆動開発 (test driven development: TDD) のすすめ GoogleAnalyticsAPI on EC-CUBE 土日で作るコンパイラ OPEN ERPに挑戦3 OPEN ERPに挑戦2 OPEN ERPに挑戦 ERPはたくさんあれど・・・ OpenGLで3D、やってみよう Recent Comments No Responses. Recent Trackbacks テスト駆動開発 (test driven development: TDD) のすすめ 06/11 » Yahooキーワード抽出... みなさんはサーバを管理するときに、何を一番気にしますか? 人によって程度の差はあるのでしょうが、誰もが気になるのが「セキュリティ」でしょ

  • OpenSSLコマンドの使い方

    以下に、直接OpenSSLのコマンドを使って、独自CAを作成する方法を説明します。 独自CAの作成 来、セキュアなWebサーバを運用するためには、認証局から、署名付きの証明書を発行してもらう必要があります。 認証局とは、CA(Certification Authority)とも呼び、証明書を発行する第三者機関のことです。 認証局を利用しないで、独自でCAの証明書を発行し、認証することもできます。 以下に、独自CAの作成方法について説明します。 ランダム情報ファイルの作成 opensslのメッセージダイジェスト機能(md5)を使って、ランダム情報ファイルを作成します。 ランダム情報ファイルは、rand.datという名前で作成します。

  • 危険タグ

    目次 │ ├メールストーム ├FDDアタック ├conconクラッシャー ├ニュースストーム ├ldapストーム ├ソースストーム ├FTP接続ストーム ├ブラウザくるくる ├ブラウザ伸び縮み ├CPUリソースフラッド ├無限アラート ├ウィンドウオープン ├無限ウィンドウオープン ├無限ファイルオープン ├以下のタグ全て表示 ├以下のタグ全て無効 ├ウィンドウを消す ├強制的に戻る ├マーキー ├強制印刷 ├巨大な字 ├大量文字 ├掲示板自動投稿 ├チカチカ ├字の上下左右変更 ├炎のような文字 ├字に影 ├危険らしいもの ├巨大な水平線 ├改行禁止回避 ├ページ強制移動 ├ブラウザ内検索 ├Winのスタッフロール ├クラッシュ ├字が変になる ├字がもっと変になる ├縦書き ├字に背景色をつける ├タグ全表示 ├オンマウスで字が消える ├オンマウスで字が巨大化 ├フルスクリーン ├ウィ