ユーザ操作のいるXSSで簡単にクリックを誘発させる手法と、XSS Auditorのバイパス方法 - 素人がプログラミングを勉強していたブログ
特に技術的に新しいものではないので公開せずに放置していたが、XSS Auditorをバイパスする方法はいろいろあるので気をつけましょうという話。 XSS Auditorをバイパスする方法は、Chrome XSS Auditor - SVG Bypass - Hack 2 Learnを参考にした(最新版ではすでにこの手法は塞がれた)。 実演と解説 見た方がわかりやすいと思うので、動画にしたので見てほしい。 これはある大学のログイン画面に存在するXSSで、 login.php?fromURL=xxx">Please complete the captcha before proceeding.<br><svg width=242px height=65px><a><image href=https://i.imgur.com/6W1W2jE.png/><animate attributeNam
「Kaspersky Free」のインストール方法及び使い方について
皆様、こんばんは。 今回の投稿は、日本においても知名度の高い「Kaspersky Internet Security」の無償版である「Kaspersky Free」というセキュリティソフトに関する投稿となります。 それでは今回の投稿にまいりましょう。 【スポンサーリンク】 はじめに さて改めまして今回の投稿は、日本においても知名度の高い「Kaspersky Internet Security」の無償版である「Kaspersky Free」というセキュリティソフトに関する投稿になります。 2017年7月25日に「Kaspersky Internet Security」の開発元である「Kaspersky Lab」というセキュリティベンダーから、「Kaspersky Free」という名称の無料版セキュリティソフトが全世界に向けて公開されました。 まずは以下の「Kaspersky Free」という
HTTPSを使ってもCookieの改変は防げないことを実験で試してみた
寺田さんのブログエントリ「他人のCookieを操作する」には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えることはあまりないのですが、残念ながらまだ読んでいない人が多そうだと言うことと、より広い読者に向けて具体的に説明した方がよいだろうと考えました。 そこで、通信路上に攻撃者がいる典型例として、公衆無線LANの偽AP（アクセスポイント）があるケースを題材として、「HTTPSを使ってもCookieの改変は防げない」ことを説明します（Secure属性使うと盗聴は防げますが、改変は防げません）。長いエントリなので結論を先に書いておきます。 Secure属性がないCookieはHTTPSでも盗聴できる Cookieの改変についてはSe
とも ちゃ日記(Tomo cha) - 元大学生のＯＬ日記-
わたしの日記は日々の出来事の鬱憤晴らしの毒だし日記がメインです。 相当病んでいます。くだを巻いています。許容出来る方のみのアクセスをお願いします。 また、この日記へのリンクは原則自由にして頂いても結構ですが、 写真への直リンクを張るのはご遠慮下さい。内容に関しては、一切保証致しません。 カテゴリ一覧 Network, Internet, IPv6, DC, NTT, Comp, Linux, Debian, FreeBSD, Windows, Server, Security, IRC, 大学, Neta, spam, 食, 生活, 遊び, Drive, TV, 仕事, 妹とやりとりしていた昨年末のこと。 私が家の中や車の中で使っている ロゴス 寝袋 ミニバンぴったり寝袋・-2(冬用)[最低使用温度-2度] 72600240をみて、こんな事言ってきた。 「東京の友達の家に泊まりに行ってディ
ポートノッキングで10秒間だけsshdを公開する設定 - hnwの日記
先日Twitterに次のような書き込みをしたところ思ったより反応が良かったので、詳細の設定を紹介します。 UDP53番、TCP443番、UDP123番とポートノッキングをするとTCP443番に10秒だけsshdが現れる、という中二病全開の設定をした。皆様にもお勧めしたい。— hnw (@hnw) 2017年3月26日 といっても特殊なことをしたわけではなく、knockdでポートノッキングの設定を行い、iptablesと組み合わせて実現しました。 ポートノッキングとは ポートノッキングというのは、決められたポートを決められた順番で叩くことでファイアーウォールに穴を空けられるような仕組みのことです。ポートノッキングを使えば、TCPの7000番、8000番、9000番の3ポートにパケットを送りつけると22番ポート (SSH) へのアクセスが許可される、といった設定ができます。 ポートノッキングの
（短いビット長の）RSA暗号を解いてみる - clock-up-blog
なんでもセキュリティ Advent Calendar 2016 15日目の記事です。 RSA鍵を作るにあたっては鍵長を十分に長くする必要があります。（この「十分に」というのは時代とともに（マシンスペックが上がるにつれ）変わっていくでしょう） 最近だと 2048ビット = 256バイトの鍵を作るのが一般的でしょうか。 この長さが短いと割と簡単に公開鍵から秘密鍵が割り出せてしまいます。 今回やること 今回は長さが十分で無いRSA公開鍵から秘密鍵を割り出す実験をしてみます。 準備 秘密鍵の準備 64ビット = 8バイトという極めて短い長さの鍵を作ります。 $ openssl genrsa -out private.pem 64 Generating RSA private key, 64 bit long modulus .+++++++++++++++++++++++++++ .+++++++
cookie経由のXSSの話 脆弱性"&'<<>\ Advent Calendar 2016 (4日目) - ooooooo_qの日記
この記事は脆弱性"&'<<>\ Advent Calendar 2016の4日目の記事です。 前日の記事はHack Patch!: CyVDB-1118関連です。 今回の記事は、eval(document.cookie)になるようなことは避けましょうという内容です。 cookie 経由でのXSSについて。 cookieに値を入れるにはサーバサイドからのレスポンスヘッダーかjavascriptからの操作になります。XSSなどがない限り攻撃者が値を入れることはできなそうですが、以下のような条件により可能です。 HTTP通信のMITM クエリパラメータをcookieに載せる実装 別サブドメインからの攻撃 ヘッダインジェクション 他 特にHTTP通信から攻撃する方法は徳丸先生の記事によるものが詳しく（HTTPSを使ってもCookieの改変は防げないことを実験で試してみた | 徳丸浩の日記）、これを
sslh でport443 を有効活用して、sshもhttpsも同時に待ち受けする。 - それマグで！
443ポート以外が絶滅しそうです あちこちでポートは閉じられています。ssh や sftp もプロキシ利用も、各種ポートでは、全く外部に出れず、接続できないネットワークが多いです。 TCP/IPなのにIPとポートを使った通信ができない、壊れたネットワークが当然になりました。 これらの接続制限にとても不便を感じることが多いです。 サーバー管理者の気分一つでポートが空いたり閉じたり、私が触ってたネットワークではポリシーが統一されず、クソネットワーク管理者に振り回されて、動くはずのものが動かず、不便なことが多かったのです。そこで仕方なく４４３を使っています。 私達が利用する端末では80/443 のポートの外部接続が閉じられることは少なく、443であれば通信できます。 そのため、443ポートに様々なアプリケーションを起動していると思います。 443 ポートとIPアドレスが枯渇する・・・ よほどのG
実例に学ぶXSS脆弱性の発見と修正方法/line_dm 16 20160916 how to find and fix xss
LINE Developer Meetup in Fukuoka #16 http://connpass.com/event/38413/
Masato Kinugawa Security Blog: hiddenなinput要素でユーザー操作を使わずにXSS
徳丸さんがブログで紹介されたことで、<input type=hidden>でのXSSが話題になっていますね！ hiddenなinput要素のXSSでJavaScript実行 | 徳丸浩の日記 http://blog.tokumaru.org/2016/04/hiddeninputxssjavascript.html 僕もちょうど、個人での検証の過程で発見した、hiddenでのXSS手法について、そろそろ共有しようと思っていたところでした。皆の関心が高いうちに、もう1つの方法を共有したいと思います！ 徳丸さんのコードに倣って紹介します。今回は問題を簡単にするためにX-XSS-Protection:0をつけさせてもらいます。 <?php header('X-XSS-Protection:0'); header('Content-Type:text/html;charset=utf-8'); ?
新入社員のためのWAF(Web Application Firewall)入門 | DevelopersIO
佐々木です。クラスメソッドも4月から新しい仲間が増えました。今日はWAF(Web Application Firewall)の基本的な知識を整理してみました。 基礎知識 WAFとは WAF(Web Application Firewall)とは、Webアプリケーションの脆弱性を狙う悪意ある通信(攻撃)から、Webアプリケーションを保護するものです。本来論で言えば、Webアプリケーションに脆弱性があるのであればWebアプリケーションを修正するのが正しい対応です。しかし未知の脆弱性があったり、修正コストが大きくWebアプリケーションでの対応が難しい場合や、緊急度が高くすぐに防御しなければならないが修正が間に合わない場合も、残念ながらあります。ユーザーとWebアプリケーションの間にWAFを入れることで、悪意ある通信を防ぐことが出来ます。 ファイアウォールとは ファイアウォールは、IPヘッダやTC
Facebookの検索機能で携帯番号が表示されてしまう問題と対処法まとめ - いまトピ
非公開にしていてもfacebookの検索で自分の携帯番号が他人に知られてしまう可能性がある？ ということがわかったので、注意喚起の意味を込めて記事にまとめました。 ことの発端は知らない番号からショートメッセージが来たこと。 僕がTVに出たということを書いているので迷惑メールでは無いっぽいし、たぶん知人の誰かだろうけど相手がわからない。 そのまま相手に 「あなたは誰ですか？」と聞くのも失礼なので まずは番号をグーグル検索しました。 当然、出ませんよね。 今どきネットに携帯番号を公開している人なんていないので、すべての電話番号を機械的に網羅したページだけが並びます。 そして本題はここから。 何気なしにその時開いていたfacebookの検索ボックスに携帯番号を入れたら、 表示されたのです。 番号の持ち主が。 確かに、少し遠い知り合いでした。 誰なのかわかってよかった。 けれど友達も、共通の友達も
ハッシュ衝突でTLSを破るSLOTH攻撃(CVE-2015-7575)とは何か - ぼちぼち日記
0. 簡単なSLOTH攻撃のまとめ 最初に簡単なまとめを書いておきます。長文になりそうなので、読むのが大変な方はここだけ見ておいてください。 MD5ハッシュは既に安全ではなく、証明書の署名方式での利用は停止されていたが、後方互換のためハンドシェイクデータの署名方式にRSA-MD5が今でも利用できるTLS実装が幾つか存在していた(Firefox NSS, Java等)。 先週、INRIAグループからハッシュ衝突を利用して実際にTLSを破る攻撃(SLOTH)が公開された。それを受け、いくつかの実装でRSA-MD5を完全に利用不能にする修正が行われた(CVE-2015-7575)。 SLOTHでは、SHA1やTLS、IKE、SSHに対する攻撃についても評価を行い、幾つかは全く現実的に不可能なレベルではないことが示された。MD5とSHA-1でTLSハンドシェイクの完全性を担保しているTLS1.0/
Apacheセキュリティ設定 - Qiita
概要 Apache の設定について共通化できるセキュリティ設定とその各項目についてまとめた。 設定例 必須設定 cat << _EOF_ > /etc/httpd/conf.d/security.conf # バージョン情報の隠蔽 ServerTokens ProductOnly Header always unset "X-Powered-By" # httpoxy 対策 RequestHeader unset Proxy # クリックジャッキング対策 Header always set X-Frame-Options "SAMEORIGIN" # XSS対策 Header always set X-XSS-Protection "1; mode=block" Header always set X-Content-Type-Options "nosniff" # XST対策 Trace
Masato Kinugawa Security Blog: IE/EdgeのXSSフィルターを利用したXSS
English version: http://mksben.l0.cm/2015/12/xxn.html ------------------------------------------------ 2015年12月のMicrosoftの月例アップデートで修正された、Internet ExplorerとEdgeのXSSフィルターに存在した問題(CVE-2015-6144 および CVE-2015-6176)について書きます。 2015 年 12 月のマイクロソフト セキュリティ情報の概要 https://technet.microsoft.com/ja-jp/library/security/ms15-dec.aspx 修正された問題は、2015年10月に行われたセキュリティカンファレンスのCODE BLUEで詳細を伏せて発表した、IE/EdgeのXSSフィルターの動作を利用してXS
オレオレ証明書を使ってwebrickを起動する - tumblr
railsでdevelopment環境でオレオレ証明書を使いたい場合のメモ。 thinを使っている場合が多いみたいだけど、webrickでも出来ないこともない。 underthehood.carwow.co.uk このページのコードに従っていけばちゃんと動いた。 環境 rails 4.2.2 ruby 2.1.4p265 STEP1. オレオレ証明書の作成 openssl req -new -newkey rsa:2048 -sha1 -days 365 -nodes -x509 -keyout localhost.key -out localhost.crt このコマンドでオレオレ証明書用の秘密鍵とサーバ証明書を作成。 opensslのオプションやオレオレ証明書の仕組みなどについては以下を参考にした。 d.hatena.ne.jp STEP2. 証明書をwebrickに読み込ませる 以下
公開鍵暗号 - RSA - 基礎 - ₍₍ (ง ˘ω˘ )ว ⁾⁾ < 暗号楽しいです
2018/10/22 全体的に問題があったので書き直した. 内容はほぼ変わっていない. 本記事では, 世界で最初に提案された公開鍵暗号であるRSA暗号の基礎事項について解説する. RSA暗号の動作原理について示した後, 簡単な攻撃手法の一覧を載せる. 公開鍵暗号 暗号理論, 特に現代暗号における暗号は「秘密鍵暗号(Secret-key Cipher)」, 「公開鍵暗号(Public-key Cipher)」の2種類に大分される. 秘密鍵暗号はよく知られている通り「秘密の鍵$k$を事前に共有しておき, その鍵を用いて暗号化・復号を行う暗号方式」である. これに対して公開鍵暗号は「暗号化に用いる鍵$k _ {enc}$, 復号に用いる鍵$k _ {dec}$が存在し, 暗号化・復号のそれぞれで異なる鍵を用いる暗号方式」と定義され, このうち$k _ {enc}$は一般に公開されることが多いこと
Go言語と暗号技術（AESからTLS）
最近マスタリングTCP/IP SSL/TLS編や暗号技術入門を読んでいた．理解を深めるためにGo言語で標準のcryptoパッケージを触り/実装を読みながら読んだ． cryptoパッケージは他の標準パッケージと同様に素晴らしい．Go言語にはどのような暗号化手法が実装されているのか実例を含めてざっとまとめる．なお本文に書ききれなかったものを含め全ての実装例はtcnksm/go-cryptoにある． 共通鍵暗号 まずは共通鍵暗号をみる．共通鍵暗号は暗号化と復号化に同じ鍵を用いる暗号化方式である．共通鍵暗号はブロック暗号とストリーム暗号の2種類に分けることができる．ブロック暗号は特定の長さ単位で暗号化を行う方式であり，ストリーム暗号はデータの流れを順次処理していく方式である． Go言語にはブロック暗号としてDES（Data Encryption Standard），DESを繰り返すtriple-D
AWS Solutions Architect ブログ
お知らせ： 本ブログ記事でも紹介されているホワイトペーパー"AWS Best Practice for DDoS Resiliency"の日本語訳が公開されました。こちらよりダウンロードできますので是非ご参照ください。 分散型サービス妨害攻撃（DDoS）はネットワークや、システム、アプリケーションを、それらが処理できる以上のトラフィックやコネクション、リクエストにより溢れさせる企てとして有害な攻撃者により時折用いられるものです。 当然のことながら、お客様はしばしばこの種の攻撃から私達がどのようにお客様のアプリケーションを守ることを支援できるのか尋ねられます。 お客様の可用性を最大化する支援をするため、AWSはDDoS対策アーキテクチャーを構築するためにAWSのスケールを活用できるようにするベストプラクティスを提供しています。 これらのベストプラクティスは"AWS Best Practice
Linux ワークステーションのためのセキュリティチェックリスト | POSTD
対象読者 これは、プロジェクトのITインフラへのアクセスや管理でLinux ワークステーションを使用しているシステム管理者向けの資料です。 システム管理者が遠隔から管理をしている場合は、ワークステーションが主要なセキュリティ条件を満たしていることを確認することで、ITインフラ全体へのサイバー攻撃の進入経路となることを防ぐことができます。その際、ここに書いたガイドラインを参考にしてください。 システム管理者が遠く離れた場所にいない場合でも、携帯可能なノートパソコンを使用している可能性や緊急対応用に自宅から会社のネットワークにアクセスできるよう設定している可能性があります。いずれの場合でも、環境に合ったガイドラインの適用をお勧めします。 制約事項 これは、「ワークステーションの強化」を徹底した資料とは言えません。しかし、これが明白なセキュリティ上のエラーを起こすのを回避できる基本的ガイドとなれ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
