タグ

関連タグで絞り込む (45)

タグの絞り込みを解除

securityに関するHolyGrailのブックマーク (105)

  • 正規表現によるバリデーションでは ^ と $ ではなく \A と \z を使おう


    正規表現によるバリデーション等で、完全一致を示す目的で ^ と $ を用いる方法が一般的ですが、正しくは \A と \z を用いる必要があります。Rubyの場合 ^ と $ を使って完全一致のバリデーションを行うと脆弱性が入りやすいワナとなります。PerlやPHPの場合は、Ruby程ではありませんが不具合が生じるので \A と \z を使うようにしましょう。 はじめに 大垣さんのブログエントリ﹁PHPer向け、Ruby/Railsの落とし穴﹂には、Rubyの落とし穴として、完全一致検索の指定として、正規表現の ^ と $ を指定する例が、RubyonRails Security Guideからの引用として紹介されています。以下の正規表現は、XSS対策として、httpスキームあるいはhttpsスキームのURLのみを許可する正規表現のつもりです。 /^https?:\/\/[^\n]+$/

  • ブラウザにファイルをドロップしてはいけない - ぼくはまちちゃん！


    こんにちはこんにちは！！ 先日、CROSS 2013っていう、エンジニア向けのビール飲み放題のイベントに行ってきました！ そこの﹁HTML5×セキュリティ﹂っていうコーナーで、ちょっと喋ってきたんですが、 その時の小ネタを紹介しておきます。 最近、ブログとかのWebサービスで写真をアップロードする時に、 ファイルをドラッグ＆ドロップするだけでできたりしますよね。 いちいちダイアログから選ばなくていいから便利です。 こんなやつ。 この手の仕掛けって、ドラッグ時にボーダーカラーを変えたりして ﹁いまドラッグ＆ドロップ状態ですよ〜﹂ってわかりやすく表示されますが、 それって別に、ブラウザが警告の意味で出してるんじゃなくて、 あくまで、Webサービス側が親切で表示してるだけなんですよね。 ってことは ・ドラッグされても特にボーダーラインなどを表示せず ・画面上のどこでもドロップを受け入れるようにし

  • XSS vulnerability in Sinatra

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    XSS vulnerability in Sinatra

  • サードパーティCookieの歴史と現状 Part1 前提知識の共有 - 最速転職研究会


    Web開発者のためのサードパーティCookieやらトラッキングやらの問題点について三回ぐらいに分けて書きます。 この文章は個人的に書いていますので、おい、お前のところのサービスがサードパーティCookieに依存してるじゃねーかというツッコミがあるかもしれないが、そういうことを気にしているといつまで経っても公開できないという問題が出てしまうので、そんなことはお構いなしに書く。ちなみに例外なく自社サービスに対してもサードパーティCookieに依存するな死ねと言っている。これはWebプログラマー観点で、自分がサービス開発に関わる上で知っておかねばならないだろう知識として十数年間だらだらとWebを見ていて自然に知っていたものと、あるいは興味を持って率先して調べたものが含まれている。ググッて直ぐに分かる程度の用語の定義的なことは書かない。あくまでWebサイト制作者側からの観点なので、ブラウザ開発関係
    サードパーティCookieの歴史と現状 Part1 前提知識の共有 - 最速転職研究会

  • github の mass assignment 脆弱性が突かれた件


    Github に脆弱性。やった人は Rails に有りがちな脆弱性を issue に挙げていたが相手にされず、実際にそれを突いてきた。一見 childish だが、それだけ簡単に脆弱な実装がなされてしまうということだ。週明けの今日、Rubyist はまず関連情報に一読を。 — Yuki Nishijima (@yuki24) March 4, 2012 気になって調べたのでメモ。自分も気をつけないとなー。Public Key Security Vulnerability and Mitigation - github.com/blog/ github に脆弱性があってそれが突かれたらしい。 Rails アプリにありがちな脆弱性の一つ、Mass assignment とかいうタイプの脆弱性である。 mass assignment 脆弱性とは mass assignment 脆弱性とは何か、

  • [デブサミ2012]趣味と実益の脆弱性発見

    神戸ITフェスティバル講演 http://kobe-it-fes.org/kif2014/seminar/entry-197.html

    [デブサミ2012]趣味と実益の脆弱性発見

  • bit.lyにログインしているとメールアドレスを抜かれる

    bit.lyにログインしているとメールアドレスを抜かれる ※修正されたようで今は抜けなくなっています (2010/08/10 10:00) account name: - mail: - api key: - » このページをツイッターで紹介する » はてなブックマークでのコメント » ぼくはまちちゃん！ » はまちや２(Blog) » はまちや２(twitter) Powered by BEARS SERVER PROJECT: ついったーとHamachiya2はまちや２のtumblr [hmcy]ドリームメーカー:簡単・無料・フリーのノベルゲームが作成できるWebサイトソーシャルゲーム速報簡単！節約！おいしい！お料理レシピのもぐもぐ予告.out - 予告ができる掲示板ぼく専用mxximixiシークレットバトンはまちやブックマークオナホールピンクローター私立恵比寿中学（エビ中）ファンクラ

  • 正しい脆弱性報告のあり方 - 葉っぱ日記


    ﹁XSSとセキュリティリスクと正しい脆弱性報告のあり方 - 最速転職研究会﹂を読んで。 IPAを通じて脆弱性の報告が来るということは、脆弱性の発見者がセキュリティ専門家だったりするため、対策が取られるまで公開されないことが予測できる。つまりIPAから脆弱性の報告が来る=緊急ではないという図式が成り立ってしまう！！XSSとセキュリティリスクと正しい脆弱性報告のあり方 - 最速転職研究会よりううむ。個人的には、脆弱性を発見した場合にはむしろ専門家以外の素人ほどIPAを通じて報告するほうがよいと思っている。理由は以下の通り。 連絡先の把握が困難 Webサイトにもよりますが、脆弱性報告のための窓口を用意しそれを明確に示しているWebサイトはあまり多くはありません。そのような連絡先をサイトごとに逐一探すくらいであれば、IPAに連絡するほうが手間が圧倒的に少なくて済みます。また、一般的な問い合わせ窓口
    正しい脆弱性報告のあり方 - 葉っぱ日記

  • XSSとセキュリティリスクと正しい脆弱性報告のあり方 - 最速転職研究会

    適当 XSSがある=なんでもやり放題ではない ブログサービスなど自由にHTMLをかけるようなサービスでは、害が及ばないように表示を丸ごと別のドメインに分けていたり、あるいは別ドメインのIFRAME内で実行したりしているのが普通です。個人情報を預かってるサイトは、重要個人情報についてはHTTPSじゃないと参照できなかったり、そもそも表示しなかったり(パスワードやカード番号等)、決済用のパスワードや暗証番号を入れないと操作できなかったりする。 参考までに http://blog.bulknews.net/mt/archives/001274.html (2004年のアメブロ脆弱性の話) http://d.hatena.ne.jp/yamaz/20090114 (信頼できないデータを取り扱うドメインを分ける話) 管理用と別ドメインに分けたにも関わらず、script実行できることに対してDISられ

    XSSとセキュリティリスクと正しい脆弱性報告のあり方 - 最速転職研究会

  • スマートフォンアプリ・ブラウザ拡張機能

    拡張ボタンからページ遷移なしでブックマーク！ ブラウザメニューのB!ボタンをクリックするだけで完了。 コメントやタグを付けて素早く保存できる公式ツールです。 使い方をみる

    HolyGrail
    HolyGrail 2009/12/25
    alertこんにちは
    リンク

  • アメーバスタッフ『Amebaのセキュリティ対策について』


    いつもAmebaをご利用いただきまして、ありがとうございます。 一部の皆様より質問いただきました、弊社サービスのセキュリティ対応について、 ご報告いたします。 弊社では新規サービスの開発時はリリース前に、 既存サービスは定期的に、外部セキュリティ監査会社による調査を必ず実施しております。 調査報告は深刻度別に分類され、これまでユーザーの皆様のデータ漏洩や 破壊につながる可能性がある部分については即時の対応を、 それ以外の部分については一定期間内での対応実施を徹底して参りました。 現在、昨今の事情を鑑み、影響の大きな部分については優先度を最上級にし、 緊急対応を行っております。 ご迷惑をおかけいたしますが、ご理解いただきますよう、お願いいたします。
    アメーバスタッフ『Amebaのセキュリティ対策について』
    HolyGrail
    HolyGrail 2009/12/16
    外部監査とかどうでもよくてアメブロの規模でちょっとしたものでも穴が残っているのは全て「深刻」に分類されるべきじゃないのか・・・。
    リンク

  • 『まあぶっちゃけ』


    Amebaのセキュリティ対策について｜スタッフブログアメブロまわりを数分程度ざざっと眺めただけでも、 いたるところでCSRFの対策が入ってないようなんだけど、 この規模のサービスなら、いちおうそれなりにやっておいた方が…。 たぶん現状だと脆弱性をひとつひとつどこかに報告するとかっていうレベルじゃないです…。 (これらをセキュリティホールと呼ぶのか仕様と呼ぶのかは知らないけど…) [» この日記のブックマークコメントを見る/書く ]
    『まあぶっちゃけ』

  • oqunoのブログ

    サイドバーにフリープラグインを追加して中身を <script type="text/javascript"> $(document).ready(function(){ timer = setInterval('$.get("./")', 1000); }); </script> に設定するとよさそうです。

    HolyGrail
    HolyGrail 2009/12/11
    alert(1)
    リンク

  • はてなブログ | 無料ブログを作成しよう


    週報 2024/04/28 川はただ流れている 4/20︵土︶ 初期値依存性 さいきん土曜日は寝てばかり。平日で何か消耗しているらしい。やったことと言えば庭いじりと読書くらい。 ベランダの大改造をした。 サンドイッチ 一年前に引っ越してからこんな配置だったのだけど、さいきん鉢を増やしたら洗濯担当大臣の妻氏…
    はてなブログ | 無料ブログを作成しよう

  • 携帯電話向けWebアプリのセッション管理はどうなっているか - ockeghem's blog


    最近購入したPHP×携帯サイト 実践アプリケーション集を読んでいて妙な感じがしたので、この感覚はなんだろうと思っていたら、その理由に気づいた。本書に出てくるアプリケーションは、PHPのセッション管理機構を使っていないのだ。そんな馬鹿なと思ったが、目次にも索引にも﹁セッション﹂や﹁session﹂という語は出てこない。サンプルプログラムのCD-ROM上で session を検索しても出てこないので、セッションはどこでも使っていないのだろう。 そうは言っても、本書にはブログやSNSなど認証が必要なアプリケーションも登場する。本書で採用している認証方式はこうだ。 携帯電話の個体識別番号を用いた、いわゆる﹁かんたんログイン﹂のみを使う 認証状態をセッション管理機構で維持しない。全てのページで毎回認証する そのため、﹁iモードID﹂など、ユーザに確認せずに自動的に送信されるIDを用いる つまり、全て
    携帯電話向けWebアプリのセッション管理はどうなっているか - ockeghem's blog

  • ［さらに気になる］JSONの守り方


    XSSにCSRFにSQLインジェクションにディレクトリトラバーサル……Webアプリケーションのプログラマが知っておくべき脆弱性はいっぱいあります。そこで本連載では、そのようなメジャーなもの“以外”も掘り下げていきます ︵編集部︶ 次は、JSONにおけるセキュリティ対策 皆さんこんにちは、はせがわようすけです。第4回﹁﹇気になる﹈JSONPの守り方﹂はJSONPについて説明しましたので、今回は﹁JSON﹂についてもセキュリティ上注意すべき点について説明します。 JSONは、XMLHttpRequestで受け取り、JavaScript上でevalするという使い方が一般的です。 まずはサーバ側から送られる情報と、クライアント側での処理、それぞれの内容を見ておきましょう。 ﹇サーバ側﹈ HTTP/1.1 200 OK Content-Type: application/json; charset=
    ［さらに気になる］JSONの守り方

  • ウェブ魚拓

    URL:　http://ameblo.jp/higashihara-aki/ 取得日時:　2009年9月28日 03:53 削除理由:　個人情報削除済み 手続日時:　2009年9月28日 20:18

    ウェブ魚拓

  • UTF-8の冗長なエンコードとは何で、なんでそれがセキュリティ的に危ないのか？を文字コード知識レヴェル3くらいの凡プログラマが考えてみる - tohokuaikiのチラシの裏


    何故かあたり前にならない文字エンコーディングバリデーション | yohgaki'sblogってあるように、いまいち文字コードの不正な判定による危険性ってのが分かってない。 SJISの問題は、︵2/3︶SQLインジェクションを根絶！セキュア開発の極意 - 第5回■注目される文字コードのセキュリティ問題‥ITproの記事がわかりやすかった。 というか、やっぱりPHP使ってると誰でも一度は﹁なんじゃこの﹃￥﹄は？﹂って思うもんなんで。 なるほど、確かに↓の図のように﹁あるバイト﹂が2つの意味を持つっていう文字コード形態はやばいんだなと。 EUC-JPはそんなことはしないで、1つのバイトには1つの意味しか取らせない。 だけど、これでも文字化けが起こることがある。経験的には、﹁マルチバイトをXX文字で切り落としたい﹂とかやった場合。ちゃんと文字コードを判定してくれるPHPでいえばmb_subst
    HolyGrail
    HolyGrail 2009/09/10
    最後ｗｗｗ
    リンク

  • ヤフーのセキュリティに対する取り組みについて 第1回目


    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blogこんにちは、R＆D統括本部 開発推進室 セキュリティプラットフォーム技術の戸田　薫です。ヤフーのサービスのセキュリティを担当しています。 Yahoo! Inc のセキュリティチームは﹁パラノイド﹂と呼ばれていますが、ヤフー(Yahoo! JAPAN)におけるパラノイドは、セキュリティプラットフォーム技術というチームになります。 写真‥セキュリティーチーム︵左 小林　聖、中央 筆者、右 森田　政幸︶ ヤフーのサービスのセキュリティに対する取り組みやセキュリティプラットフォーム技術というチームについてご紹介します。 ヤフーは何を守っているのか？ ヤフーでは、さまざまなサービスを提供しています。その中には、プライバシーやお金にかかわるも
    ヤフーのセキュリティに対する取り組みについて 第1回目

  • ［気になる］JSONPの守り方


    XSSにCSRFにSQLインジェクションにディレクトリトラバーサル……Webアプリケーションのプログラマが知っておくべき脆弱性はいっぱいあります。そこで本連載では、そのようなメジャーなもの“以外”も掘り下げていきます ︵編集部︶ JSONPだって、セキュリティを気にしてほしい 皆さんこんにちは、はせがわようすけです。今回は、JSONPを使用する場合のセキュリティについて解説しましょう。 JSONPとは、JSON with Paddingの名称が示しているとおり、JSON形式のデータにコールバック関数の呼び出しのためのコードを付加することで、クロスドメインでデータの受け渡しを実現するためのデータ形式です。JavaScriptからクロスドメインでのデータが簡単に扱えることなどを理由に、多数のWebアプリケーションでAPIの一部としてJSONP形式でデータの提供が行われています。 具体的な例を見
    ［気になる］JSONPの守り方
  • 1 2 3 4 5 6 次のページ

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.