Burp Suiteで脆弱性診断
こんにちは。坂本です。 今回は脆弱性診断ツールができるBurp Suiteというツールを紹介します。 このセキュリティ界隈では知らない人はいない有名なツールです。 Burp Suiteは脆弱性診断に必要な機能を揃えています。 ・Webサイトへリクエストする情報を改ざんして脆弱性がないか確認する機能 ・WebサイトをクローリングしてURLのリストを取得する機能 ・取得したURLに対して脆弱性がないか診断をする機能 などなど この機能を実現するためBurp Suiteはプロキシサーバとなります。 プロキシとなったBurp SuiteはWebサイトとブラウザの間に入りリクエストを傍受し脆弱性診断を行うことができます。 Burp Suiteの購入から起動 Burp Suiteで脆弱性診断をするにはライセンスを購入する必要があります。 まずは公式サイトでBurp Suiteのダウンロードを行います。
LINE Security Bug Bounty Program
プログラム情報 1. プログラムの目的 本プログラムは、コミュニケーションアプリ「LINE」及びWEBサイトに存在する脆弱性を早期に発見し、ユーザーに、より安全なサービスを提供することが目的です。 2. プログラムの詳細について 2019年10月より、LY CorporationはHackeroneというプラットフォーム上でLINE Security Bug Bounty Program（以下「本プログラム」という）を運営しております。つきましては、脆弱性の報告はこちらのフォームをご利用ください。 また、Hackeroneをご利用になれない場合や、本プログラムとは関係のないバグの報告等は dl_bugreport@linecorp.com へのメールにて受け付けております。 ただし、脆弱性報告フォーム以外からの報告は、原則として報奨金の対象外となりますのでご注意ください。 3. 利用規約
シェルスクリプトの平文パスワードをセキュアにする方法 - 余白の書きなぐり
追記: (2015/8/3) 大量のはてブが付いたので 続き を書きました。 sshを使用している人は文字列を手軽に暗号化・復号化できるという話。 このテクニックを使えば色々セキュアになるのでおすすめ。 今回はシェルスクリプト中の平文パスワードをセキュアに代替する。 平文パスワードはやめよう シェルスクリプト中でパスワードが必要になったとき、 とりあえず平文で書いてしまいがち。 #!/bin/sh PASSWORD="hoge" これをセキュアにしたい。 面倒くさいのは嫌なので、なるべく手持ちのツールで暗号化、復号化したい。 ssh用の rsa 秘密鍵と、openssl(大抵の環境に入っている)を使って改善しよう。 秘密鍵の準備 パスワードを暗号化するにあたって、秘密鍵を使用する． sshを常用している場合は ~/.ssh/id_rsa という秘密鍵が存在するだろう。 もし秘密鍵が無ければ
情報処理推進機構：情報セキュリティ：脆弱性対策：安全なウェブサイトの作り方
「安全なウェブサイトの作り方」は、IPAが届出(*1)を受けた脆弱性関連情報を基に、届出件数の多かった脆弱性や攻撃による影響度が大きい脆弱性を取り上げ、ウェブサイト開発者や運営者が適切なセキュリティを考慮したウェブサイトを作成するための資料です。 「安全なウェブサイトの作り方」改訂第7版の内容 第1章では、「ウェブアプリケーションのセキュリティ実装」として、SQLインジェクション 、OSコマンド・インジェクション やクロスサイト・スクリプティング 等11種類の脆弱性を取り上げ、それぞれの脆弱性で発生しうる脅威や特に注意が必要なウェブサイトの特徴等を解説し、脆弱性の原因そのものをなくす根本的な解決策、攻撃による影響の低減を期待できる対策を示しています。 第2章では、「ウェブサイトの安全性向上のための取り組み」として、ウェブサーバの運用に関する対策やウェブサイトにおけるパスワードの取扱いに関す
SHAAAAAAAAAAAAA | Check your site for weak SHA-1 certificates.
SSL certificates are signed using a one-way hash — usually SHA-1. Which is too bad, because SHA-1 is becoming dangerously weak. It's time to upgrade to SHA-2. Getting a SHA-2 certificate You'll need to generate a new certificate request, and get your CA to issue you a new certificate using SHA-2. Using your existing private key: openssl req -new -sha256 -key your-private.key -out your-domain.csr S
警察からの問い合わせ電話にこたえるにあたって - davsの日記
警察からの照会電話がたびたびかかってくる職場で働いていたことがある。 警察からの照会だからこたえることが許される、あるいはこたえなければならない照会が多かったのだが、必ず守らなければならないルールがあった。 それは、その電話ではこたえず、一旦、電話を切ることだった。その後、ネットなりで警察本部や警察署の代表番号を調べて、回答の電話をかけるのだ。それはもちろん、警察をかたる電話を警戒してのことだが、この警察からの問い合わせへの回答ルールには続きがあった。 問い合わせ電話の担当を把握していても、その人物を電話口に呼び出さず、「こういう照会があったのですが、担当者を失念しました。問い合わせされたのはどなたですか」というのだ。これは、照会者が真正な警察官であっても、公務でない照会をしていることを恐れるためだ。乱暴な要約をすれば、悪徳警官でないかを心配しているということだ。前段の警察の代表番号にかけ
WiresharkでSSL通信の中身を覗いてみる - ろば電子が詰まつてゐる
OpenSSLの脆弱性「Heartbleed」が世間を賑わせていますが、色々と乗り遅れてしまった感があるので、ゆるゆると落ち穂拾いをしようかと思います。 Heartbleedで秘密鍵を手に入れたらSSL通信の中身全部見えちゃうじゃん!! という事態になっていますが、なんとなく理論的にそうだろうなと分かるもののイマイチ具体的な手順が分からない。 というわけで今回のテーマとして、手元にサーバの秘密鍵と、SSL通信をパケットキャプチャしたpcapファイルがあるときに、Wiresharkでどんな感じでSSL通信を「ほどく」のか……という具体的な手順を、ハマり所を含めてまとめておこうかと思います。 というか、私自身がハマったので自分用メモですな。なおこの文書では"SSL"とだけ記述し、TLSは無視しています。 前提条件 とりあえず以下のような感じの検証環境で試しました。 IPアドレス 説明 ホストO
InfoQ: HTTPSコネクションの最初の数ミリ秒
ほとんどの人がHTTPSとSSL (Secure Sockets Layer) を結びつけて考えます。SSLは1990年代半ばにNetscape社が開発した仕組みですが、今ではこの事実はあまり正確でないかもしれません。Netscape社が市場のシェアを失うにしたがって、SSLのメンテナンスはインターネット技術タスクフォース(IETF)へ移管されました。Netscape社から移管されて以降の初めてバージョンはTransport Layer Security (TLS)1.0と名付けられ、1999年1月にリリースされました。TLSが使われだして10年も経っているので、純粋な"SSL"のトラフィックを見ることはほとんどありません。 Client Hello TLSはすべてのトラフィックを異なるタイプの"レコード"で包みます。ブラウザが出す先頭のバイト値は16進数表記で0x16 = 22。 これは
AWSの共有責任モデル（shared responsibility model）
The document discusses Amazon Web Services (AWS) Batch and how it can help customers run batch computing workloads on AWS. It notes that AWS Batch automatically provisions the optimal quantity and type of compute resources (e.g., EC2 instances) required to run jobs efficiently. It also allows customers to integrate their own scheduling and application code with AWS Batch through simple API calls o
開発者のための正しいCSRF対策
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
QRコードを物理的に乗っ取ってマルウェア配布に使う攻撃が増加 | スラド セキュリティ
携帯電話を使ってスキャンするだけでウェブサイトに移動できるという手軽さで多用されているQRコードだが、これを利用した新たなマルウェア配布方法が増えてきたそうだ（Help Net Securitiy、本家/.）。 ＱＲコードを使った攻撃は以前からあったが（QRコードを利用した攻撃に注意、QRコードを使ったフィッシングに気をつけろ！）、最近目立っているのが既存のQRコードの上に不正なQRコードを貼り付けることで不正サイトへ誘導するというもの。街の中心部や空港など人が多く集まる場所がターゲットとなっており、広告やその他お知らせなどに掲載されているQRコードに不正QRコードが貼付けられるケースが確認されているという。 QRコードだけから不正なものかどうかを見分けるのは難しく、スキャンしてしまった人を簡単にフィッシングサイトや悪意あるサイトのURLへ誘導することが可能とのこと。 身を守るには、開く前
セッションID管理は結局どうすれば良いのか？
(Last Updated On: 2018年8月18日)脆弱性やセキュリティ対策について技術的な話ばかりしていたので「それで結局PHPのセッション管理どうすれば良いの？」と思われた方も多いと思います。簡単にまとめます。漏れや追記した方が良い事などがあったらご指摘ください。 session_regenerate_id()の使い方（セッションID再生成） ログイン処理時・ログアウト処理には最初にsession_regenerate_idを呼ぶ。 定期的にsession_regenerate_idを呼ぶ。間隔が短いほど低リスク。 session_regenerate_idはtrueオプション（古いセッションデータ削除）を付ける。 session_regenerate_idでtrueオプションは付けない。その代わりに再生成した時点のタイムスタンプを古いセッションデータに記録し、数分後からそのセッ
雑然紛然？ ここが変だよ、日本のモバイルアプリとAPT！
Appthorityは、社内に持ち込まれる私用デバイスの安全な接続と利用を促進するためのソリューションを提供している。特にモバイルアプリは、開発時のミス次第で攻撃者の突破口となり、企業システムの脅威となってしまうことから、世界各国のモバイルアプリを収集し、検証を行っているという。 ベッティーニ氏は、日本で人気のあるゲームアプリの中から、面白いと感じたものをいくつか紹介した。その説明を基に、著者の独断と偏見で「開発ミスでやっちゃった系」「広告収入が欲しい系」「よく分からない系」に分類してみた。 開発ミスでやっちゃった系 「拡散性ミリオンアーサー」 iOSアプリ（バージョン1.3.1）。RFC1918のプライベートIPアドレスで通信するため、社内の無線LANなどに入ってゲームをした場合に問題が生じる可能性がある。「たぶん、アプリ開発者が自社の開発環境でテストマシンにアクセスするとき、この設定を
【Twitter実験】つぶやきだけで個人を特定できるのか？ | オモコロ
こんにちは、セブ山です。 みなさんはTwitterでどんなつぶやきをしていますか？ おそらく、今日の予定をつぶやいたり、ランチの写真をアップしたり、あなたの「今」を仲の良い友達に向けてつぶやいていることでしょう。 しかし、本当にそのツイートはあなたの友達だけが見ているのでしょうか？ もし、知らない誰かにあなたのつぶやきを覗かれていたとしたら…？ つぶやいた内容を手掛かりに個人を特定されてしまうかもしれませんよ！？ 今回は、そんな個人情報垂れ流し社会に警鐘を鳴らす実験をおこないます！！ ■ルール説明 １．Twitterの検索機能を使って「渋谷なう」とつぶやいているアカウントを探します。 ２．「渋谷なう」の検索結果をもとに、さらに詳細な個人情報を垂れ流しているアカウントを割り出します。 ３．そのアカウントのつぶやきをこっそり監視して、個人を特定し、実際に捕まえるためにハンター（セブ山）が渋谷の
Webアプリケーションに対する広範なDoS攻撃手法(hashdos)の影響と対策
28C3(28th Chaos Communication Congress)において、Effective Denial of Service attacks against web application platforms（Webプラットフォームに対する効果的なサービス妨害攻撃）と題する発表がありました（タイムスケジュール、講演スライド）。 これによると、PHPをはじめとする多くのWebアプリケーション開発プラットフォームに対して、CPU資源を枯渇させるサービス妨害攻撃(DoS攻撃)が可能な手法が見つかったということです。この攻撃は、hashdos と呼ばれています。 概要PHPなど多くの言語では、文字列をキーとする配列（連想配列、ハッシュ）が用意されており、HTTPリクエストのパラメータも連想配列の形で提供されます。PHPの場合、$_GET、$_POSTなどです。 連想配列の実装には
「SQLインジェクション対策」でGoogle検索して上位15記事を検証した - ockeghem's blog
このエントリでは、ネット上で「SQLインジェクション対策」でGoogle検索した結果の上位15エントリを検証した結果を報告します。 SQLインジェクション脆弱性の対策は、既に「安全なSQLの呼び出し方」にファイナルアンサー（後述）を示していますが、まだこの文書を知らない人が多いだろうことと、やや上級者向けの文書であることから、まだ十分に実践されてはいないと思います。 この状況で、セキュリティのことをよく知らない人がSQLインジェクション対策しようとした場合の行動を予測してみると、かなりの割合の人がGoogle等で検索して対処方法を調べると思われます。そこで、以下のURLでSQLインジェクション対策方法を検索した結果の上位のエントリを検証してみようと思い立ちました。 http://www.google.co.jp/search?q=SQLインジェクション対策 どこまで調べるかですが、以前NH
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SSL Server Test (Powered by Qualys SSL Labs)
httpsだからというだけで安全？調べたら怖くなってきたSSLの話!？ - Qiita
就活生のみなさんへ ～文系？理系？～ « サーバーワークス社長ブログ
Engadget | Technology News & Reviews
