Web開発者はもっと「安全なウェブサイトの作り方」を読むべき - Flatt Security Blog
画像出典: https://www.ipa.go.jp/files/000017316.pdf こんにちは。株式会社Flatt Security セキュリティエンジニアの奥山です。 本稿では、独立行政法人 情報処理推進機構(以下、IPA)が公開している資料「安全なウェブサイトの作り方」を紹介します。 「安全なウェブサイトの作り方」は、無料で公開されているにも関わらず、Webセキュリティを学ぶ上で非常に有用な資料です。これからWeb開発やセキュリティを勉強したいと考えている方はもちろん、まだ読んだことのない開発者の方々にも、ぜひ一度目を通していただけたらと思います。 一方、「安全なウェブサイトの作り方」では、一部にモダンなアプリケーションには最適化されていない情報や対象としていない範囲が存在します。それらについても本記事で一部、触れていきたいと考えていますので、資料を読む際の参考にしていただ
開発者が知っておきたい「XSSの発生原理以外」の話 - Flatt Security Blog
はじめに こんにちは。株式会社Flatt Securityのセキュリティエンジニアの冨士です。 本稿では、XSS(クロスサイトスクリプティング)が攻撃に用いられた時のリスクの大きさを紹介していきます。以降はクロスサイトスクリプティングをXSSと記載していきます。 XSSはセキュリティエンジニアならもちろん、開発を行っているエンジニアの多くの方が知っている脆弱性です。ですが、私はWebアプリケーションの脆弱性診断を行ってきた経験の中で多くのXSSを目にしてきましたし、依然として検出率の多い脆弱性の一つだと感じています。 その認知度や、一般的な対策方法のハードルの低さ(設計や仕様によっては対策工数が大きい場合もありますが)にも関わらずXSSの検出率が多いのは、直感的にリスクがわかりづらく、アラートをあげるだけの紹介が多いことが一つの要因ではないかと考えています。 すなわち、興味範囲が「どのよう
Chromeに入るRecorder機能の利用と注意点 - 虎の穴開発室ブログ
こんにちは。虎の穴ラボのH.Hです。 今回は先日発表されたChromeの開発中の新機能であるRecorder機能について使用方法や利用する際の注意点などをまとめました。 Recoder機能とは ブラウザのChrome97で追加される予定の機能で、ブラウザの画面上で操作した記録を取得してくれる機能になります。 この記事を書いている2021年11月17日では一般に提供されているChromeの最新版は96となり、開発中の「Chrome Dev」もしくは「Chrome Canary」でRecorder機能を使用することができます。 利用している時の様子はChromeの開発者向けのページに公開されています。 developer.chrome.com 主な機能は以下の通りです。 ・操作の記録及び再実行(リプレイ)できる ・再実行時にパフォーマンスの記録・確認できる ・記録した内容の編集ができる ・操作
登大遊氏が語る「おもしろインチキ ICT 技術開発」の重要さとは | さくマガ
日本は研究開発を進化させ、1990 年代にはさまざまな産業分野で世界トップになりました。 ICT の分野でもこれが可能であり、そのためには「おもしろインチキ ICT 技術開発」が必要になる、と登さんは語ります。 日本の ICT とセキュリティ技術の生産手段確立と産業化の実現について、JAIPA Cloud Conference2021 に登壇された、登大遊さんのお話をまとめました。 登 大遊 氏 プロフィール VPN システムやテレワーク技術等を開発・製品化。オープンソースで全世界に 500 万ユーザーを有する。外国政府のけしからん検閲用ファイアウォールを貫通する研究で博士 (工学) を取得。2017 年より独立行政法人 情報処理推進機構 (IPA) サイバー技術研究室を運営。2020 年に NTT 東日本に入社して特殊局を立ち上げる。ソフトイーサ株式会社を 16 年間経営中。 登大遊氏が
みずほ銀行システム障害に学ぶ
みずほ銀行システム障害の調査報告書が公開されたのがニュースになって、Twitterなどで色々な人がコメントをしているのを見た。140文字しか書けない空間で他人の失敗談の揚げ足取りをするのは簡単だが、そこからは一時の爽快感以外に何も得るものがないので、僕はそういうのはカッコ悪いと思っている。 そこで、ちゃんと読んでみたら全く他人事でない部分も沢山あるし、非常に面白く勉強になったので、ブログにまとめてみる。 技術的な話 銀行のシステムがどのようになっているのか、全然イメージが湧いていなかったので、それがまず勉強になった(p.29)。 トラフィックのソースに応じて用意された色々なシステムから基幹システム「MINORI」の取引メインバスにトラフィックが流れ、そこから各種システムへとリクエストが送られていく。この辺はService Oriented Architectureらしい。開発当時としては（
ちょっとでもセキュリティに自信がないなら、 Firebase Authentication を検討しよう
note のやらかしのあのへんについて。 認証自作、 Rails 、 Devise - Diary パーフェクト Rails 著者が解説する devise の現代的なユーザー認証のモデル構成について - joker1007’s diary 認証サーバーの実装は本質的に難しいです。セキュリティが絡むものは「簡単な実装」などなく、プロアマ個人法人問わず、個人情報を守るという点で、同じ水準を要求されます。悪意あるハッカーは常にカモを探していて、もし認証が破られた場合、自分だけではなく大多数に迷惑が掛かります。初心者だから免責されるといったこともありません。全員が同じ土俵に立たされています。 とはいえ、認証基盤を作らないといろんなサービスが成立しません。そういうときにどうするか。 Firebase Authentication で、タイトルの件なんですが、 Firebase Authenticat
Web開発者がおさえておきたい10のセキュリティ技術 ～カギは事前の対策にあり OWASP Proactive Controls
はじめに 脆弱性対応に追われる状況は、開発からデプロイまでの時間を浪費し、またサイバー攻撃への対応力を弱めがちです。そこで、開発者が最初からセキュアにソフトウェアを構築する能力を身につける必要性が高まっています。前回の記事では、深刻な影響のある10の脆弱性についてまとめた「OWASP Top 10」から、それぞれの脆弱性についての解説や、開発者の方に活用してほしいOWASPコミュニティの成果物を紹介しました。OWASP Top 10によりソフトウェア・セキュリティの世界の扉を開くきっかけになれば幸いです。 OWASP Top 10では各脆弱性の概要、脆弱性の有無の確認方法、防止方法などを理解できることを紹介しました。このドキュメントは、脆弱性そのものを軸として説明がなされていることから、事前の対策、すなわち脆弱性が発生しないようにするための防止方法を軸として見た視点とは異なっています。その
WordPress で Web サイトの制作を請け負って保守契約も結ぶときに意識しておいたほうが良い5つのこと
反応をウォッチしていると「WordPress を導入する場合、セキュリティを考えると当然システム保守契約を結んで保守することが必要」という意見がちらほらあって、僕としてもそれは当然のことでむしろやっていない人は作成した後えらいことになってないのか少し心配になったりしてしまうのですが、じゃあクライアントと保守契約を結べたとしてどういうことに気をつけたほうが良いかということを少し書いてみたいと思います。 コア・プラグインのアップデートは必ず実施する 大前提すぎてあれなのですが、セキュリティを維持して攻撃を防ぐためにお客様にシステム保守契約を結んでいただくわけなので、コアやプラグインのバージョンアップは必ず行わないといけません。企業さんのサイト制作の場合だとテーマはオリジナルのことが多いと思いますが、テーマも自作でないのであればきちんとアップデートするべきです。 「コアの自動アップデートをとめる
プログラマとして30年以上の経験から得た教訓 | POSTD
私は、プログラマとして30年以上仕事をしてきた中で、学んだことがあります。そのいくつかを以下にご紹介します。もっと挙げることもできますよ。 実物を見せないと、顧客の希望は分からない。 このことは最初の仕事で学びました。顧客は、実物を見るまでは、何が本当に必要なのかがよく分かりません。言葉で長々と説明するよりも、機能検証のためのプロトタイプを提示する方が確実に役立ちます。 十分な時間があれば、あらゆるセキュリティは破られる。 現代社会において、セキュリティを保つことは信じられないほどの難題となっています。プログラマは常に完璧を求められますが、ハッカーは1回でもハッキングができれば成功なのです。 セキュリティが破られた場合、事前にその状況に備えた対策を講じているかどうかで結果が変わってくる。 最終的にセキュリティが破られることを想定する場合、その時に起こることに備えて対策を立てておく必要があり
OS X キーチェーンから環境変数をセットするツールを作りました - クックパッド開発者ブログ
こんにちは、技術部の福森 (@sora_h) です。 最近は環境変数に API トークンや credential といった認証情報を入れる事が増えてきています。 たとえば、AWS を利用するツールでは AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY といった環境変数にだいたいの場合で対応しています。 そのため、~/.bashrc や ~/.zshrc などシェルの設定に export を書いておき常に使える状態にしている方も多いと思いますが、 それって実は危険ではないでしょうか? 例えば、下記のようなリスクが考えられます: 意図せず情報が利用されて意図しない副作用が発生してしまう危険性 本番に変更を与えるつもりはなかったけれど事故を起こしてしまう等 悪意のあるスクリプトを実行した際に環境変数を送信などされてしまう危険性 事故や漏洩を防ぐためにも、筆者はかな
文字コードの脆弱性はこの3年間でどの程度対策されたか?
2019/01 JSUG勉強会の資料です。 この資料でDisっているのはJPAではなく、 ・何も考えずに「標準だから」というだけでJPAを選ぶ人 ・OSSに全くコントリビュートせずにフリーライドする人 です。
単純ではない、最新「クロスサイトスクリプティング」事情
単純ではない、最新「クロスサイトスクリプティング」事情：HTML5時代の「新しいセキュリティ・エチケット」（2）（1/3 ページ） 連載目次 皆さんこんにちは。ネットエージェントのはせがわようすけです。第1回目は、Webアプリケーションセキュリティの境界条件であるオリジンという概念について説明しました。 現在のWebブラウザーでは、同一オリジンのリソースは同じ保護範囲にあるものとし、オリジンを超えたアクセスについてはリソースの提供元が明示的に許可しない限りはアクセスできないという、「同一オリジンポリシー（Same-Origin Policy）」に従ってリソースを保護しています。 その保護範囲であるオリジンを超え、リソースにアクセスする攻撃の代表事例であるクロスサイトスクリプティング（XSS）について、今回、および次回の2回に分け、HTML5においてより高度化された攻撃と、その対策を説明しま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch
SIOS Tech. Lab – エンジニアのためになる技術トピックス