2023/08/26(土)に開催された Frontend Nagoya #11 のセッションで使用したスライド資料です。
「Yuzo Related Posts」など人気のWordPressプラグインを狙った攻撃活動が観測されているとしてセキュリティベンダが注意を呼び掛けており、また国内でも関連が疑われる被害報告が上がっています。ここでは関連する情報をまとめます。 3月以降脆弱性が確認されたプラグイン 2019年3月以降、脆弱性の悪用が報告されたプラグインは次のもの。 No 報告日 対象のプラグイン インストール数 バージョン 脆弱性 1 2019/03/15 Easy WP SMTP 40万件超 1.3.9以前 管理者への特権昇格 2 2019/03/21 Social Warfare 6万件超 3.5.2以前 XSS(格納型)、任意コードの実行 3 2019/03/30 Yuzo Related Posts 6万件超 5.12.91以前 XSS(格納型) 4 2019/04/09 Visual CSS S
こんにちは。Typetalkチームの永江です。今回は4月にリリースした、BacklogとTypetalkの連携機能である「Backlogカード」の実装の際に行った クリックジャッキング対策 について説明します。 Backlogカードとは Backlogカードは、Typetalkのトピック内にBacklogの課題やコメントをカード形式にして表示する機能です。Backlogの課題キーや課題のURLを貼り付けるだけで、以下の画像のように表示できます(※詳しいご利用方法についてはこちらの「Typetalkのトピック上で課題の詳細を見られる Backlogカード をリリースしました!」をご参照ください)。 Backlogカードの実装は、TypetalkからBacklogに用意した埋め込み用の課題ページを<iframe>で表示するというものです。このような実装にしたのは、もともとBacklogに<if
安全で堅牢なWebアプリケーションをクラウドで開発するのは 非常に困難 です。それを簡単だと思っているような人は、例えばとんでもない頭脳をお持ちというなら別ですが、遠からず痛い目を見ることになるでしょう。 もし MVP(Minimal Viable Product:必要最低限の機能を備えた製品) のコンセプトを鵜呑みにして、有益かつ安全な製品を1ヶ月で作成できると考えているようなら、プロトタイプを立ち上げる前に一度考え直した方がいいと思います。以下に挙げたチェックリストをご覧いただければ、セキュリティに関するクリティカルな問題の多くをスキップしていることが分かるはずです。あるいは少なくとも、潜在的なユーザに対しては 誠実 であるように心がけ、製品が完全ではないこと、そしてセキュリティが不十分な製品を提供していることを伝えるようにしてください。 このチェックリストはシンプルなもので、決して完
LINE Developer Meetup in Fukuoka #16 http://connpass.com/event/38413/
調査の結果、これらのPHPファイルが改ざんされたことにより、Webサイトからのレスポンス内に不正なコードが、閲覧者のアクセス毎に動的に挿入されていたことが判明しました。 改ざんされたPHPファイルによって不正なコードが挿入される仕組み 改ざんされたPHPファイルには、「//istart」および「//iend」というコメントに挟まれた、図 1のような不正なPHPコードが挿入されていました(不正なPHPコードが難読化されている場合も確認しています)。 この不正なPHPコードは、外部から取得したコードを挿入する機能を持っており、特定のURLから不正なコードを受け取り、特定の位置に挿入します。 図 1: 「//istart」および「//iend」に挟まれた不正なPHPコード 挿入される不正なコード Webサイトに閲覧者がアクセスすると、改ざんされたPHPファイル中の不正なPHPコードは、図 2のよ
Googleが「HTTPS everywhere」を提唱していることなどが影響して、HTTPSで通信できるようにWebサイト全体を独自ドメインに対してSSL/TLSによる暗号化を行い、運用をスタートしている様子がちらほら私の周りには増えてきました。 Google ではさらにもう一歩踏み込んで、数か月前の Google I/O では、「HTTPS everywhere」をウェブで提唱しました。 ユーザーがもっと安全にサイトを閲覧できるよう、すべてのサイト所有者の皆様に HTTP から HTTPS への切り替えをおすすめしたいと考えています。 (Google ウェブマスター向け公式ブログ: HTTPS をランキング シグナルに使用しますより) 私はしばらく動向を伺っていましたが「Webサイト全体をHTTPSへ切り替える流れは今後はより加速すると考えてもいい」と判断をし、このブログも全体をHTT
IPA(独立行政法人情報処理推進機構、理事長:藤江一正)は、ウェブサイトの開発者や運営者向けの「安全なウェブサイトの作り方」にパスワードリスト攻撃への悪用防止対策等を新たに追加した改訂第7版を2015年3月12日(木)からIPAのウェブサイトで公開しました。 URL:https://www.ipa.go.jp/security/vuln/websecurity.html IPAでは、必要な技術的配慮が不足していたために起こるウェブサイトの情報漏えいや改ざん等、意図しない被害を防ぐため「安全なウェブサイトの作り方」を2006年から発行しており、これまでに6版を数えています。その内容には、IPAへの届出件数が多く攻撃による影響度が大きいソフトウェア製品やウェブアプリケーションに関する脆弱性関連情報を取り上げ、適切なセキュリティが考慮されたウェブサイト作成のためのポイントをまとめています。 7版
ブログやWebサイトのパフォーマンスの改善やSEO、セキュリティの向上に役立つ.htaccessの設定を紹介します。 ドメインをwww有り・無しに統一、新ドメインに引っ越した時のリダイレクト、URLをクリーンなものにしたり、共有サーバーでのPHPのバージョンを指定したりなど、すぐに利用できるものばかりです。 .htaccess Snippets -GitHub 元記事には有用な.htaccessのスニペットがPublic Domainでまとめられおり、それら全部に加えて.htaccessファイルの作成と使い方を加えました。 .htaccessファイルの作成と使い方 リライトとリダイレクトの設定 セキュリティの設定 パフォーマンスの設定 その他のいろいろ有用な設定 .htaccessファイルの作成と使い方 「.htaccess」ファイルを作成することは非常に簡単です。 テキストベースのアプリ
Web サイトを常時 SSL 化する場合に、最低限知っておかなければならない知識や、注意点、実際の設定方法まで、ひと通りまとめてみました。メリットやデメリット、証明書の種別からリダイレクト設定などについても解説しています。 HTTPS をランキングシグナルに使用しますと Google が公式に発表したあたりから、Web サイトの SSL 対応、特に Google が推奨している Web サイトをすべて HTTPS で配信する、所謂 「常時 SSL 化」 についての話を聞いたり、実際にお客様から相談されたりするケースが増えてきました。 そこで、いい機会だしその辺に関する情報をまとめておこうかな~ と思って書いてみた、恒例の (?) 5分でわかるシリーズ。書き終わって見たところ絶対に 5分じゃ無理っていう文章量になっててどうしようかなぁとも思ったんですが、気にせず公開してみます。 常時 SSL
ポイントは下記の通りです。 X社(原告)はセキュリティ対策について特に指示はしていなかった 損害賠償について個別契約に定める契約金額の範囲内とする損害賠償責任制限があった 当初システムはカード決済を外部委託し直接カード情報を扱っていなかった X社が「カード会社毎の決済金額を知りたい」とY社に依頼をして、その結果カード情報をいったんDBに保存する仕様となった(2010年1月29日) X社からの問い合わせに対してY社は、カード情報を保持しない方式に変更することが可能で、そのほうが安全となり、費用は20万円程度である旨を伝えた(2010年9月27日)が、その後X社は改良の指示をしなかった 以下の脆弱性その他が認められた システム管理機能のIDとパスワードが admin/password であった 個人情報が記載されたお問い合わせログファイルの閲覧が可能(ディレクトリリスティングと意図しないファイ
毎年恒例の「初心者Webアプリケーション開発者がチェックすべき情報源」を集めているので、皆さんにもご紹介。 去年は手を広げすぎてかえって反応が悪かったので、最低限のものに絞ってみた。 上から重要な順。★の付いている「重点」がとりあえず読んどけ、の必須。 必須のポイントは、短期間で大雑把に網羅的にポイントが整理されているものを選択。 書籍としては、徳丸本「体系的に学ぶ 安全なWebアプリケーションの作り方」、「めんどうくさいWebセキュリティ」と「実践 Fiddler」を掲載。 「HTML5 を利用したWeb アプリケーションのセキュリティ問題に関する調査報告書」を追加。 ■重点 ★Webサイト構築 安全なウェブサイトの作り方 http://www.ipa.go.jp/security/vuln/websecurity.html LASDECなどで公開されていたウェブ健康診断仕様が別冊に加わ
WEBサービスにおけるセキュリティ対策の基礎 近年WEBサービスの脆弱性が騒がれておりますが、果たしてあなたが運用しているサイトのセキュリティは大丈夫でしょうか?以下、チェックしておくべきセキュリティ項目をあげました。 SSL証明書の利用 ユーザのプライベートな情報を送信してもらいサーバに保存するようなサービスではSSL認証は必須の機能と言えるでしょう。SSL認証を行っていないと、大切なユーザの情報が外部の悪いユーザに見られてしまう可能性があります。 ※ちなみにGozal-mediaではプライベートな情報のやり取りは行っていないためhttpで通信を行っています。 【確認方法】 ・ユーザ情報を送受信するページのURLが「https」から始まっている事を確認 ・「https」のページにアクセスした際に「セキュリティ証明書が信頼できない」という用な表示が出てこない事を確認 【導入方法】 導入
OWASP Japan、Webアプリの一般的なセキュリティ要件をまとめた文書公開:開発者にも、そして発注者にも安全なWebアプリの要件定義を OWASP Japanは2013年11月1日、Webシステム/Webアプリの開発において一般的に盛り込むべきと考えられるセキュリティ要件をまとめた「Webシステム/Webアプリケーションセキュリティ要件書」を公開した。 OWASP Japanは2013年11月1日、「Webシステム/Webアプリケーションセキュリティ要件書」を公開した。安全なWebアプリケーションを実現するため、開発を依頼する発注者側と、実際に開発を担う受注者側の双方が留意すべき要件についてまとめている。 The Open Web Application Security Project(OWASP)は、Webアプリケーションのセキュリティ改善に向けた啓発、研究活動を行う非営利団体だ
スタックオーバーフロー対策をする場合、関数の入口でチェックすれば大抵対策可能なんだけど、それだと対策漏れの可能性があるから、例えば、strcpyの代わりにstrncpyあるいはもっと高機能な文字列関数を使うことが当然になってきました。 これは、入口でのチェックだと漏れやすいから、脆弱性が発生するその箇所で対策するという考え方にシフトしているのだと私は考えます。 Webアプリケーションの場合も同様で、XSSやSQLインジェクションの対策は、脆弱性の発生する箇所、すなわち、HTMLの生成とか、SQLの呼び出しの時点で行います。いや、これらは「セキュリティ対策」ではなく、全ての文字を扱うために必要なエスケープ処理に過ぎないので、例がよくないですね。例えば、パストラバーサル脆弱性対処のためのファイル名の確認は、ファイルをオープンする直前(ファイル名を使う直前)に行うべきだ、という考え方です。 スタ
wp-login.phpの変更 WordPressブログを自己防衛、ログインページに触れさせない [解決済み] wp-login.phpのパーミッションとファイル名変更 – WordPressフォーラム セキュリティの為、管理画面を別名にしたら問題が出るでしょうか? - WordPressフォーラム 不正アクセスはある日突然やってくる – おきらくサーバー運用メモ WordPress セキュリティ wp-login.php にアクセス多発を防ぐ方法 – Linux & App Labs By pt106 あぁ、なるほど。IP制限だけでなくてもBASIC認証かけて2重にしとくって手も良いですね。 プラグイン 2012年開幕版!これでモウダイジョーブなWordPressプラグイン集 最強77選 WordPressのセキュリティ関連のプラグイン28個 – わーどぷれすっ! セキュリティを強化す
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く