当社アプリ（Android版）においてアプリの権限を求める件について | お知らせ | NEOBANK 住信SBIネット銀行
当社アプリのAndroid版バージョン5.0におきまして起動時にアプリの権限を求めることがございます。こちらは2020年7月31日にリリースを行いました「スマート認証NEO」の仕様によるものとなります。 いずれの権限も当社がお客さまの個人情報や他アプリの情報等を取得するものではございませんので、何とぞご理解賜りますようお願い申し上げます。 「スマート認証NEO」はサービスを利用するスマートフォンのみに保存された本人確認情報を利用して認証を行う方式で、従来のパスワードに変わる新しい認証技術（FIDO※）を用いています。認証に用いるデータがネットワークを経由せず端末のみに保管されているため、IDやパスワードなどの認証情報が漏洩するリスクが低く、より安心安全なお取引が可能となります。 また、当社「スマート認証NEO」ではFIDOの標準仕様に準拠して実装されており、お客さまのスマートフォンに保存さ
テレビが勝手に通信してるを調べた時のメモ（テレビ朝日） - Qiita
テレビのインターネット接続機能 「テレビ視聴データに関する民放５社共同の技術検証および運用実証実験」ってニュースが流れてたけど、そもそも「テレビ視聴データって何？」「どうやって取ってるの？」「Dボタンを押さなくても勝手に通信するの？」と疑問が浮かび調べてみた。 この記事で扱っているデータは、5社共同実験の期間終了後なので、他社と視聴ログを共有しない「テレビ朝日 - 視聴データの取扱いについて」の挙動と考えます。 この記事では扱っておりませんが、他局（ フジテレビ / TBS / テレビ東京 / 日本テレビ / NHK ）からも同様の告知が出ていることから、他局も同様の機能を持っていると考えられます。 作業環境 スイッチは「NETGEAR GS108Ev2」 テレビを接続したポートからパケットキャプチャを接続したポートへのミラーポートを設定。 パケットキャプチャは「Wireshark」 「テ
Auth TokenをlocalStorageに入れようが、cookieに入れようがどっちもXSS危険性には無防備（同ドメイン内なら ...） - Qiita
Auth TokenをlocalStorageに入れようが、cookieに入れようがどっちもXSS危険性には無防備（同ドメイン内なら ...）JavaScriptcookieJWTxsstoken tokenを保存する場所 localStorage cookie cookie (http only) メモリ内 (変数) よく言われるのが JWT tokenをlocalStorageに入れるべきではない ということ。 理由としてはJavascriptで簡単に読めてしまうので、XSSがあった場合意図しないスクリプトを動かされてしまい、結果としてtokenが盗まれるというもの。 対応策として cookie (http only) を色んな所で推奨してる。 https://techracho.bpsinc.jp/hachi8833/2019_10_09/80851 http://cryto.net
これで完璧！今さら振り返る CSRF 対策と同一オリジンポリシーの基礎 - Qiita
✎ 基礎知識編 CSRF とは何か？ CSRF (Cross-Site Request Forgeries) を意訳すると 「サイトを跨ぐ偽造リクエスト送信」 です。 簡単に言うと，罠サイトを踏んだ結果，自分が無関係な別のサイト上で勝手にアクションをさせられる攻撃です。具体的には，ネットサーフィンをしているうちに知らない間に自分のIPアドレスから掲示板に犯罪予告が書かれていた，といった被害を受けます。 この攻撃を防ぐ責任は「無関係な別のサイト（具体例では掲示板）」側にあります。Web サイト作成者には，利用者が意図しない操作を勝手に実行されないように，利用者を守る責任があります。 また上図からも分かる通り，この攻撃の最大の特徴はアカウントがハッキングされたというわけではないということです。ログイン状態の利用者のWebブラウザを利用して攻撃が行われている，というのが重要です。 オリジンとは何
二段階認証(TOTP)メモ - Qiita
二段階認証のアプリは色々あるらしいが(IIJ Smartkey、Authy、Google Authenticator等)、どうやら TOTPというワンタイムパスワードの規格があり、それに沿っている模様。 RFC6238 Time-based One-time Password Algorithm (TOTP)の仕組みのメモ http://qiita.com/shrkw/items/426a7f1a59f42e0bd523 そのうち使うかもしれないのでメモ。 QRコード(URIフォーマット) 多くの二段階認証アプリはQRコードで登録するが、実際のURIは以下のようになっている。 otpauth://totp/Example:hoge@example.com?secret=JBSWY3DPEHPK3PXP&issuer=Example otpauth://totp/[LABEL]?[Param
bcryptの72文字制限をSHA-512ハッシュで回避する方式の注意点
宅ふぁいる便から平文パスワードが漏洩した件を受けて、あらためてパスワードの安全な保存方法が関心を集めています。現在のパスワード保存のベストプラクティスは、パスワード保存に特化したハッシュ関数（ソルトやストレッチングも用いる）であるbcryptやArgon2などを用いることです。PHPの場合は、PHP5.5以降で使用できるpassword_hash関数が非常に便利ですし、他の言語やアプリケーションフレームワークでも、それぞれ用意されているパスワード保護の機能を使うことはパスワード保護の第一選択肢となります。 なかでもbcryptは、PHPのpassword_hash関数のデフォルトアルゴリズムである他、他の言語でも安全なハッシュ保存機能として広く利用されていますが、パスワードが最大72文字で切り詰められるという実装上の特性があり、その点が気になる人もいるようです（この制限はDoS脆弱性回避が
BCryptのすすめ - Qiita
はじめに この記事は Scala Advent Calendar(Adventar) の13日目です。パスワード保存に使うBCryptの話をします。 安全にパスワードを保存する 皆様、パスワードをセキュアに保存しているでしょうか？まさかとは思いますが、パスワードを生で保存するとかおぞましいことをしてないでしょうか？ パスワードは攻撃者によってソースコード・DBすべて取得されたとしても、元のパスワードを類推することを不可能とするように保存することにより、パスワード漏洩最後の砦として機能させることが望ましいです。 この条件を満たす方法として、パスワードをHash化して保存する方法があります。ただし単純なHash化では駄目です。まず、類推されにくくて衝突しずらい、暗号学的に良いHash関数アルゴリズムが必要です。また、よくあるHash関数アルゴリズムは(元々高速に計算することを意図していたのもあ
HTML5のLocal Storageを使ってはいけない（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Randall Degges - Please Stop Using Local Storage 原文公開日: 2018/01/26 著者: Randall Degges 日本語タイトルは内容に即したものにしました。 画像は元記事からの引用です。 追記（2021/10/18） Local Storageについては徳丸先生の以下の資料もおすすめです。Local Storageは使い方次第という観点で解説しています。 PHPカンファレンス2021の資料です / “SPAセキュリティ入門～PHP Conference Japan 2021” https://t.co/7B7exX2kWB — 徳丸 浩 (@ockeghem) October 3, 2021 追記（2022/08/23） 以下の徳丸先生のツイートからリンクされている記事も
JWT・Cookieそれぞれの認証方式のメリデメ比較 - Qiita
JWTとは JSON Web Tokenの略。ジョットと読むらしい。 ざっくりいうとJsonに電子署名を加え、URL-Safeな文字列にしたTokenのこと 正確にいうと、電子署名を使用する方式はJWS（JSON Web Signature）と呼ばれ、別途暗号化を使用するJWE（JSON Web Encryption）も存在する。よく見かける説明はJWS方式のほう。 JWS方式の場合、電子署名であり暗号化ではないため、中身を見ることは可能。但し改ざんはできない、という仕組み。 実際のユースケースで言うと、サーバ側で認証情報が入ったJsonを加工（電子署名を加える等）し、JWTにしたのち、それを認証Tokenとしてクライアントに渡す。クライアントはそのTokenを認証Tokenとして使用する。 仕組みについては調べればたくさん出てくるのでそちらを参照したほうが良いかと思います。 この記事では
JWTは使うべきではない 〜 SPAにおける本当にセキュアな認証方式 〜 - Qiita
React/Redux/Spring Boot/AWSでSPAを作っているのですが 認証の方式をどうするか悩みました。 ベストと思われる認証方式をこちらに記載することにしました（随時更新します）。 JWTは使うべきじゃない ログイン済みであるという事実を サーバーサイドのセッションを使わずに保存しておく場合、 ログインした後でJWTなどのトークンをサーバーで生成し、 それをクライアントサイドで何らかの形で保存しておく必要がある。 なぜなら、ReactおよびReduxのstateで管理してしまうと、 ページをリロードされたときにstateがクリアされてしまうから。 具体的な保存先はローカルストレージくらいしか無いのだが JWTをローカルストレージに格納するのは危険。 なぜなら、ローカルストレージはJavaScriptで簡単に読み込めてしまうから。 自ドメイン以外のJavaScriptを読み込
APIファーストでバックエンドとフロントエンドを別々に開発する時にハマるクロスドメインアクセス - Qiita
いま個人で開発を行っているWebサービスがありまして、そこではバックエンドをRubyonRails、フロントエンドをClojure & ClojureScriptで開発し、APIでお互いやりとりするように設計しています。(その設計した理由は色々ありますが、単純に好きな2つの言語を使いたかったのが大きな理由の一つですw) おそらくこれからのアプリケーション開発において、このようにフロントエンドとバックエンドをサーバーも言語も分けて設計・開発することが多くなると思いますので、最近ハマった問題をシェアしておきます。 同一生成元ポリシー(Same Origin Policy) そのハマった問題というのが同一生成元ポリシーによるAjaxの規制です。 同一生成元ポリシーとは、ドメインAに配置されているHTMLファイルから別ドメインBのサーバーのAPIにAjaxで通信することが出来ないという制約です。
Fetch: クロスオリジン(Cross-Origin) リクエスト
もし任意の web サイトから fetch を行った場合、そのリクエストは恐らく失敗するでしょう。 ここで中心となる概念は オリジン – ドメイン/ポート/プロトコルの３つ揃いです。 クロスオリジンリクエスト(これらは別のドメイン(サブドメインも)、プロトコル、あるいはポートに送信されたもの)には、リモート側からの特別なヘッダが必要です。そのポリシーは “CORS” (Cross-Origin Resource Sharing) と呼ばれています。 例えば、http://example.com へのフェッチをしてみましょう。: 予想通り、fetch は失敗します。 なぜ?なぜなら、クロスオリジン制約が悪意のあるハッカーからインターネットを保護するからです。 脱線しますが、簡単に歴史的な背景を振り返りましょう。 長い間、JavaScript はネットワークリクエストを実行するための特別なメソ
同一生成元ポリシー(Same-Origin Policy) - とほほのWWW入門
クロスサイトリクエストフォージェリ(CSRF)などのセキュリティ攻撃を防止するために、ブラウザは「同一生成元ポリシー(Same-Origin Policy)」という仕組みを実装しています。異なるオリジンのリソースへのアクセスに制約をかけるものです。制約はまた、JSONP や CORS(Cross-Origin Resource Sharing) と呼ばれる仕組みを利用することで一部解除することができます。 オリジン(Origin)は、スキーム、ホスト、ポート番号の組み合わせです。下記は同じオリジンとみなされます。 http://site-a.example.com/ http://site-a.example.com:80/ http://site-a.example.com/example.html 下記は異なるオリジンとみなされます。 https://site-a.example.co
包括的にSame-Origin Policy（同一生成元ポリシー）を理解する＜2021年版＞ - Qiita
記事の目的と想定読者 World Wide Webが世の中で比較的広く使われるようになって、すでに20年を超えました。アクセス元の主役もPCからスマートフォンになり、Webはシンプルを追求する設計思想から大きく幅を広げてきました。この記事は、主にサイトコンテンツ開発者が安全で便利なサイトを開発するための基礎知識を身につけるために通して読んでいただくこと、あるいは深く調べるためのネタ元として役立てることを念頭に置いて書いています。冗長に感じられることも多いと思いますが、お許しください。 なぜSame-Origin Policyがあるのか Same-Origin Policyって何？という話はWikipediaにお任せするとして、なぜSame-Origin Policyが必要なのかという話は根本的理解に必要不可欠なので、今さら感はありますが、ちゃんと書いておきます。 そもそもWorld Wid
マイナンバーカード未取得「理由提出を」 各省庁職員に：朝日新聞デジタル
国家公務員らによるマイナンバーカードの一斉取得を進めるため、各省庁が全職員に対し、取得の有無や申請しない理由を家族（被扶養者）も含めて尋ねる調査をしている。内閣官房と財務省の依頼を受けたもので、氏名を記入して上司に提出するよう求めている。調査を受けた職員からは、法律上の義務でないカード取得を事実上強要されたと感じるとの声が出ている。 政府はマイナンバーカードを２０２１年３月から健康保険証として使えるようにする計画で、６月に閣議決定した「骨太の方針」に、国と地方の公務員らによる今年度中のカード取得の推進を盛り込んだ。２２年度末までに国内のほとんどの住民がカードを保有するとも想定し、「普及を強力に推進する」としている。 朝日新聞は各省庁などに送られた７月３０日付の依頼文を入手した。内閣官房内閣参事官と国家公務員共済組合（健康保険証の発行者）を所管する財務省給与共済課長の役職名で、骨太の方針に基
コンテナイメージのセキュリティチェック＆脆弱性診断を簡易的に実施する - Qiita
どうも、若松です。 最近、コンテナイメージをビルドしまくっており、オレオレなコンテナイメージが増殖しています。 そんなおり、以下の記事が目に止まりました。 DockerHubで公開されているコンテナが安全か確かめてみた結果【人気のコンテナ上位800個】 そりゃあ脆弱性あるわなぁと思いつつ、じゃあオレのコンテナイメージは大丈夫か？と思いました。 というわけで上記の記事で使用されていたdockleとTrivyを使って、オレオレコンテナイメージをチェックしていきたいと思います。 使用ツール dockle CISベンチマークやDockerベストプラクティスに準拠したコンテナイメージかをチェックできます。 WARNやFATALの項目には、どのように改善すればよいかのヒントが添えられていて小憎いです それぞれの基準は以下の通り CISベンチマーク Dockerベストプラクティス Trivy OSやアプ
コンテナ・セキュリティ入門 脆弱性 - Qiita
コンテナイメージのレジストリでは、脆弱性検査の実装が当たり前になっている。企業でKubernetesなどコンテナを使用するにあたって脆弱性対策がどれほど重要なものか理解するために、脆弱性検査や、関連する国際的な標準について整理した。 脆弱性（ぜいじゃくせい）とは 脆弱性とは、プログラムの動作の不備を悪用される情報セキュリティ上の弱点である。つまり、ソフトウェア上の問題が原因となって生じた欠陥であり、セキュリティホールとも呼ばれる。当然、ソフトウェア開発者は、脆弱性を産まないように細心の注意を払ってコード開発を進めるが、開発者が利用するオペレーティングシステムのライブラリやパッケージに含まれることもある。そのような事情から、開発者の責任範囲外に原因がある場合も多くある。 潜在的な脆弱性を突いた新たなクラッキングの手口が、時間の経過ともに発見される。そのことから、開発当初はコードに脆弱性は無い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「単なるOAUTH 2.0を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる」について | SIOS Tech. Lab
知っていれば恐くない、XMLHttpRequestによるXSSへの対応方法
Amazonの「注文履歴流出騒動」、ユーザーの名前や連絡先も閲覧可能だったことをアマゾンジャパンが認める 9月26日中に問題は解消、該当ユーザーには個別に連絡・謝罪
