Shibuya.XSS techtalk #11 の発表資料です。
Shibuya.XSS techtalk #11 の発表資料です。
The npm blog has been discontinued. Updates from the npm team are now published on the GitHub Blog and the GitHub Changelog. On August 1, a user notified us via Twitter that a package with a name very similar to the popular cross-env package was sending environment variables from its installation context out to npm.hacktask.net. We investigated this report immediately and took action to remove the
Malicious packages in npm. Here’s what to do | Ivan Akulov’s blog People found malicious packages in npm that work like real ones, are named similarly real ones, but collect and send your process environment to a third-party server when you install them 訳: 悪意のあるパッケージがnpmで発見された。それらは、実際のパッケージによく似た名前で同じように動くが、パッケージのインストール時にプロセスの環境変数を外部のサーバに送信する。 発見されたパッケージの一覧は元エントリをどうぞ。このようなマルウェアである偽パッケージの一例をあげると、 ba
evalとreportOnlyについて追記しました (2016/10/10) 2016/10/20 仕様名は以下の通りになりました。Anti-XSS Response-Time Uniqueness Requirement また、ヘッダ名は、XSS-Protectionヘッダではなく、ARTURヘッダとなっておりますが、また変更される可能性があります。 Googleの調査によると、CSPによるXSSの防止は現実的にデプロイの欠陥によりXSSの防止効果がないことを示しています。調査は「CSP Is Dead, Long Live CSP!」としてACMのカンファレンスで発表され、ペーパーも閲覧することができます。 9月に行われたW3C TPAC 2016のWebAppSecのミーティングで議論され、GoogleのMike West氏より新しくXSS Protectionという仕様が提案されて
2月頃、リッチテキストエディタの TinyMCE のXSS脆弱性を報告しました。 特にセキュリティの修正をしたといったアナウンスはありませんが、数日前に公開された4.3.9でこの問題が修正されています。Twitterのプロフィールにも、「World's #1 most popular open source #WYSIWYG editor」 とあるくらい、世界的にも非常によく使われているリッチテキストエディタのようですので、更新を促すためにこの記事を書きます。 XSS脆弱性は 4.3.8 以下のバージョンにあります。 僕の知る限りでは、TinyMCEのPreview Plugin機能を使っていなければ影響を受けません。 この機能を呼び出さないようにするか、4.3.9以上に更新してください。 これ以下は、技術的な説明になります。この脆弱性の発生原因は、技術的にも少し面白いです。 発火する場所
HTML5で導入されたiframe要素のsandbox属性は、そのiframe内のコンテンツに対しJavaScriptの実行を始め様々な制約を課すことでセキュリティの向上に役立つ機能である。例えば、以下のように指定されたiframeでは、iframe内からformのsubmitなどはできるが、iframe内でのJavaScriptの実行やtarget=_blankなどによってウィンドウを開くことなどは禁止される。 <iframe sandbox="allow-forms" src="..."></iframe> sandbox属性に明示的に allow-scripts という値を指定しない限りはiframe内では直接的にはJavaScriptは実行できないが、かといってiframe内から間接的にJavaScriptを必ずしも実行させることが不可能かというとそうでもない。 sandbox属性
WebRTCセキュリティレポート あらまし WebRTC(Web Real-Time Communication)は、Webアプリケーション技術の昨今のトレンドの一つだ。WebRTCを利用すると、プラグイン無しで、また他の条件も無しでリアルタイムコミュニケーションを実現できる。だが、そのオープンソースとして性質から、WebRTCを採用しようとする人がセキュリティ上の不安を覚えることもあるだろう。本レポートはWebRTCのセキュリティについて明らかにし、他の技術と比較してWebRTCのセキュリティが優れていることを解説する。 1. 導入 WebRTCはオープンソースのWebベースの技術であり、ユーザがリアルタイムメディア通信を、プラグイン無しで実現可能な技術だ。適切なブラウザを利用すれば、ウェブサイトをブラウズするだけで、他者に発信して通話することができる。 WebRTCの主なユースケースは
合わせて読んでください:Flashと特定ブラウザの組み合わせでcross originでカスタムヘッダ付与が出来てしまう問題が未だに直っていない話 (2014-02/07) XMLHttpRequestを使うことで、Cookieやリファラ、hidden内のトークンを使用せずにシンプルにCSRF対策が行える。POSTするJavaScriptは以下の通り。(2013/03/04:コード一部修正) function post(){ var s = "mail=" + encodeURIComponent( document.getElementById("mail").value ) + "&msg=" + encodeURIComponent( document.getElementById("msg").value ); var xhr = new XMLHttpRequest(); xhr
HTTP ガイド HTTP の概要 典型的な HTTP セッション HTTP メッセージ MIME タイプ(IANA メディア種別) HTTP の圧縮 HTTP キャッシュ HTTP 認証 HTTP Cookie の使用 HTTP のリダイレクト HTTP 条件付きリクエスト HTTP 範囲リクエスト コンテンツネゴシエーション HTTP/1.x のコネクション管理 HTTP の進化 プロトコルのアップグレードの仕組み プロキシサーバーとトンネリング HTTP クライアントヒント HTTP セキュリティ サイトの安全化 HTTP Observatory Permissions Policy コンテンツセキュリティポリシー (CSP) オリジン間リソース共有 (CORS) Cross-Origin Resource Policy (CORP) Strict-Transport-Securit
このウェブサイトは販売用です! monoweb.info は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、monoweb.infoが全てとなります。あなたがお探しの内容が見つかることを願っています!
Angularとサーバーサイドテンプレートの混在 先日リリースされた某サービス(他社)がAngularを使っていて、XSSがボロボロ出てくるだとか、{{var}} な形式で値を入力するとng-template側でテンプレーティングされるだとかの話がありました。 詳しくは見ていないので、今回の話とまったく同じかは把握していませんが、サーバーサイドテンプレートを混在させると、次のようなことが起こりえます。 例えばejsとAngular サンプルとしてスカスカなControllerを用意します。 angular.module('app', []).controller('AcmeCtrl', function($scope) { $scope.foo = 'bar'; }); ejsは次のようなテンプレートになっているとします。
#基本的には、面倒な話なのであるが・・・この種のプログラムを作る上では避けられない・・・ Webブラウザーの基本的なセキュリティー実装方針として、"Same Domain Policy"というのがあり、Cookieではそれが適応されているが、XMLHttpRequest(XHR)を通じた接続はどのような状況であろうか? ユーザーが、example.com にアクセスした場合、cookieはexample.comにしかcookieを送信しないようにしているのは、ブラウザーの実装による。cookieの生成元にしかcookieを送信しない。これで、example.comとユーザーとの間のみで、プライバシーに関連するような情報を保護しようと言うのである。わかりました。同意です。 ただし、formタグからサブミットする先、scriptタグから読み込まれたスクリプトの実行は、このポリシーが適応されてい
HTML5 は、WHATWG および W3C が HTML4 に代わる次世代の HTML として策定を進めている仕様であり、HTML5 およびその周辺技術の利用により、Web サイト閲覧者 (以下、ユーザ) のブラウザ内でのデータ格納、クライアントとサーバ間での双方向通信、位置情報の取得など、従来の HTML4 よりも柔軟かつ利便性の高い Web サイトの構築が可能となっています。利便性が向上する一方で、それらの新技術が攻撃者に悪用された際にユーザが受ける影響に関して、十分に検証や周知がされているとは言えず、セキュリティ対策がされないまま普及が進むことが危惧されています。 JPCERT/CCでは、HTML5 を利用した安全な Web アプリケーション開発のための技術書やガイドラインのベースとなる体系的な資料の提供を目的として、懸念されるセキュリティ問題を抽出した上で検討を加え、それらの問題
You have to bypass: function check(str) { var tokenized = str.replace(/\\["\\\/bfnrtu]/g, "@").replace(/"[^"\\\n\r\u2028\u2029\x00-\x08\x0a-\x1f]*"|true|false|null|-?\d+(?:\.\d*)?(?:[eE][+\-]?\d+)?/g, "]").replace(/(?:^|:|,)(?:[\s\u2028\u2029]*\[)+/g, ""); var ok = /^[\u2028\u2029,:\]{}\s]*$/.test(tokenized); if (ok) { alert("Executing: eval('(" + str + ")')"); return eval("(" + str + ")"); } else
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Integrate 100+ OAuth providers in minutes. Setup your keys, install oauth.js, and you are ready to play !
Stack Overflowに面白い質問があったので紹介する javascript - Why does Google prepend while(1); to their JSON responses? - Stack Overflow 質問 Googleのサービス内で使われるJSONの先頭に while(1); てついているのは何故? 例えばGoogle Calendarではカレンダーを切り替えるときに以下のような内容のデータがサーバから返される。 while(1);[['u',[['smsSentFlag','false'],['hideInvitations','false'],['remindOnRespondedEventsOnly','true'],['hideInvitations_remindOnRespondedEventsOnly','false_true'],['C
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く