iOS Security Tutorial — Part 1
On March 25th 2019, Apple announced its new consumer U.S. credit card issued by Goldman Sachs “Apple Card”. They pointed out that for every Apple Card, there’s a unique per device card number that is created and stored safely in the device’s secure element & that every purchase is authenticated with Touch ID or Face ID. The purpose of this tutorial is to further elaborate what is the iOS device’s
Certificate pinning technique on iOS
Hi, folks! Today we are going to talk about security. To completely comprehend these concepts presented here I need to provide some background knowledge about how SSL/TLS works and other stuff. Of course, it is not a deep dive, it is just a simple explanation before starting the main subject, if you already know it, it is ok, just step out this part and go to next section. At the final we are goin
SSL/TLSネゴシエーション
◆ SSL/TLSセッションのハンドシェイク SSLクライアントとSSLサーバとでやりとりされるメッセージのなかで、以下のメッセージについては やりとりを省略した通信が行われる場合もあります。 ・ Server Certificate ・ Server Key Exchange ・ Certificate Request ・ Client Certificate ・ Certificate Verify 例えば、クライアント証明書を使用しないSSL通信であれば「Client CertificateとCertificate Verify」が省略。 ◆ SSL/TLSのメッセージ ・ Client Hello SSLの通信開始をクライアントからサーバに通知するメッセージ。メッセージに含まれている内容は以下です。 ⇒ SSL/TLSのバージョン、乱数、セッションID、クライアントが利用できる暗号
Ruby on Rails - OWASP Cheat Sheet Series
Ruby on Rails Cheat Sheet¶ Introduction¶ This Cheatsheet intends to provide quick basic Ruby on Rails security tips for developers. It complements, augments or emphasizes points brought up in the Rails security guide from rails core. The Rails framework abstracts developers from quite a bit of tedious work and provides the means to accomplish complex tasks quickly and with ease. New developers, th
Mozilla Observatory
📣︎ Heads up! New security scoring standards apply - Your website grade may have changed. MDN Observatory will launch soon. Learn More. The Mozilla Observatory has helped over 240,000 websites by teaching developers, system administrators, and security professionals how to configure their sites safely and securely.
Rails セキュリティガイド | Rails ガイド
このマニュアルでは、Webアプリケーション全般におけるセキュリティの問題と、Railsでそれらの問題を回避する方法について説明します。 このガイドの内容: 本ガイドで取り上げられている問題に対するあらゆる対策 Railsにおけるセッションの概念、セッションに含めるべき項目、有名なセッション攻撃 Webサイトを開くだけで（CSRFによる）セキュリティ問題が発生するしくみ ファイルの取扱い上の注意、管理インターフェイスを提供する際の注意事項 ユーザーを正しく管理する（ログイン・ログアウトのしくみ、あらゆるレイヤにおける攻撃方法） 最も有名なインジェクション攻撃方法の解説 1 はじめに Webアプリケーションフレームワークは、Webアプリケーションの開発を支援するために作られました。フレームワークの中にはセキュリティを比較的高めやすいものもあります。実際のところ、あるフレームワークは他のよりも安
これだけでイイ、Rails5でAPIサーバを作るときのCORS設定 - Qiita
RailsでAPIサーバを作るときにフロントエンド・アプリケーションとの連携で出てきがちなCORSの設定。 毎回調べるのがめんどくさいので、セキュリティ要件的にもテキトウにするわけにはいかないこのCORSの「とりあえずこれだけやっておけばOK」な設定をRailsとJavaScriptの実装と一緒に説明します。 CORSとは？ CORSは日本語ではHTTPアクセス制御のことで、簡単に言うと許可されていないウェブサイトからのアクセスをブロックすることで悪意のあるアクセスを防ぐための機構です。 rack-corsを導入 この記事では、デフォルトでRailsのアプリケーションの中に生成されるconfig/initializers/cors.rbというファイルに従って、rack-corsを使います。 まずはGemfileに以下を追記して、rack-corsをインストール
RailsのCSRF対策の仕組みについて - （2015年までの）odaillyjp blog
先日、Rails で開発しているときに意図しない InvalidAuthenticityToken エラーが発生して、すごくハマってしまいました。そのときに Rails のCSRF対策の仕組みについて調べてみましたので、ブログに残しておきます。 Rails のCSRF対策 Rails が生成した ApplicationController には以下の記述があります。 class ApplicationController < ActionController::Base # Prevent CSRF attacks by raising an exception. # For APIs, you may want to use :null_session instead. protect_from_forgery with: :exception end protect_from_forg
What is a Pem file and how does it differ from other OpenSSL Generated Key File Formats?
I am responsible for maintaining two Debian servers. Every time I have to do anything with security certificates, I Google for tutorials and beat away until it finally works. However, in my searches I often come across different file formats (.key, .csr, .pem) but I've never been able to find a good explanation of what each file format's purpose is. I was wondering if the good folks here at Server
Same-Origin Policy とは何なのか。 - 葉っぱ日記
ちょっと凝ったWebアプリケーションを作成していたり、あるいはWebのセキュリティに関わっている人ならば「Same-Origin Policy」(SOP)という言葉を一度は聞いたことがあると思います。日本語では「同一生成元ポリシー」あるいは「同一生成源ポリシー」などと訳されることもありますが、個人的には「オリジン」は固有の概念を表す語なので下手に訳さず「同一オリジンポリシー」と書いておくのが好きです。 さて、この「オリジン」とは何なのかという話ですが、これは「RFC 6454 - The Web Origin Concept」で定められており、端的に言うと「スキーム、ホスト、ポート」の組み合わせをオリジンと定め、それらが同じものは同一のオリジンとして同じ保護範囲のリソースとして取り扱うということです。 例えば、http://example.jp/fooとhttp://example.jp:
公開鍵暗号について理解が足りていなかったのでメモ - かせいさんとこ
これは何? github にコミットする時とか、heroku にデプロイする時とか、 認証に公開鍵使うけど、いまいちちゃんと理解していないのでまとめた 目次 暗号化の方法 共通鍵暗号 公開鍵暗号 HTTPS TLS/SSL 公開鍵証明書 SSH 公開鍵認証 具体的な手順 暗号化の方法 共通鍵暗号 送信者と受信者が共通の秘密鍵を持って、暗号化と複合を行う たとえばこんな感じ 平文 : 1234 秘密鍵 : 5678 暗号化 : 1234 x 5678 暗号文 : 7006652 復号化 : 7006652 / 5678 送信者側は、平文を、秘密鍵で暗号化して、暗号文を受信者に送る 受信者は、暗号文を、秘密鍵で復号化して、平文を得る 共通鍵暗号の弱点 最初に鍵を受信者に渡す必要があるが、その時に盗聴されるリスクがある 渡す時暗号化すれば良いけど、その暗号化の鍵を... となる 多人数で秘密の通
Masato Kinugawa Security Blog: Googleのmetaリダイレクトに存在した問題
Googleに存在したメールアドレスを窃取できた問題について書きます。これは2011年1月30日に報告し、報告後数日以内に修正された問題です。 こんなページがありました。 http://example.google.com/redirect?continue=http://example.google.com/xyz <meta http-equiv="refresh" content="0;url='http://example.google.com/xyz'"> <script> location.replace("http://example.google.com/xyz") </script> continueというパラメータに指定されたURLをmetaタグとlocation.replace()にそれぞれ入れて、JavaScriptの有効/無効の設定に関わらずリダイ
スマートフォンアプリケーションでSSLを使わないのは脆弱性か
このエントリでは、スマートフォンアプリケーションの通信暗号化の必要性について議論します。 はじめに 先日、スマートフォンアプリケーションのセキュリティに関するセミナーを聴講しました（2月8日追記。講演者からの依頼によりセミナーのサイトへのリンクをもうけました）。この際に、スマートフォンアプリケーションの脅威に対する共通認識がまだないという課題を改めて感じました。その課題を痛感できたという点で、セミナーは私にとっては有益でした。 このため、当ブログではスマートフォンアプリケーションの話題をあまり取り上げていませんでしたが、今後は、とりあげようと思います。まずは、スマートフォンアプリケーションでは暗号化を必須とするべきかという話題です。この話題は、前記セミナーでもとりあげられていました。 暗号化の目的は何か まず、暗号化の必要性を論じるためには、暗号化の目的を明確にする必要があります。前記セミ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Hide Sensitive Information in the iOS App Switcher Snapshot Image
What is a TLS/SSL certificate and how does it work? | Proton
Content Security Policy | 酒と涙とRubyとRailsと
SECCON2013 slide
情報倫理とセキュリティのためのクイックガイド
IPA セキュア・プログラミング講座
HTML5 Security Cheatsheet