PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。
AWSアクセスキーセキュリティ意識向上委員会って何? 昨今、AWSのアクセスキーを漏洩させてしまうことが原因でアカウントへの侵入を受け、 多額の利用費発生・情報漏洩疑いなど重大なセキュリティ事案が発生するケースが実際に多々起きています。 そこで、アクセスキー運用に関する安全向上の取組みをブログでご紹介する企画をはじめました。 アクセスキーを利用する場合は利用する上でのリスクを正しく理解し、 セキュリティ対策を事前に適用した上で適切にご利用ください。 【はじめに】 昨今、アクセスキーの漏洩を契機とした不正利用の発生が多発しております。AWS 利用のお客様へのビジネスリスクが非常に大きく、弊社としても憂慮する状況です。 そのため、以下をお読み頂き AWS 利用のお客様は環境の見直しをお願い致します。 【この記事で伝えたいこと】 多額の費用発生リスクをなくすために、可能な限りアクセスキーの利用を
オフェンシブセキュリティ部の山崎です。サーバサイドレンダリング(SSR)の導入によってSSRFが発生する問題を見つける機会があったため、本記事では実例を交えながら紹介したいと思います。 サーバサイドレンダリング(SSR)とは? 本記事で扱うSSRとは「サーバ上でHTMLを出力すること」を指しています。ただしerbやjspのようなテンプレートからHTMLを出力するのとは異なり、一般的には以下のようにクライアントサイドレンダリング(CSR)の文脈で使われることが主です。 近年のVue.jsやReactを代表するようなWebフロントエンドフレームワークはブラウザ上で動的にDOMツリーを構築して画面を描画(CSR)するのが主流となっています。これによってページ遷移を挟まずユーザ体験のよいシングルページアプリケーション(SPA)が作ることができるというメリットがあります。 ただ、単純なSPAにはデメ
Reactでの認証は厄介です。 Reactでコードを書いているとReduxやら外部ライブラリやら様々な「覚えること」「理解すべきこと」が出てきますが、結局ググればなんとかなることが多いです。 私がReactでアプリケーションを作るにあたって最も頭を悩ませたのが、今回取り上げる「認証」です。 認証はとにかくググっても結論が見いだせず、途方に暮れました。ネット上には様々な意見があったのですが、それらをまとめつつ私なりの結論を書いていきたいと思います。 こんな方におすすめ これからSPAの認証を学びたいという方認証について調べてみたけど、「つまり、、、どういうことだってばよ、、?」となってしまった方
2020年6月、仮想通貨取引所「Coincheck」を運営するコインチェックのコーポレートサイトに、あるセキュリティインシデントの報告書が掲載された。当時、重要な事例として筆者のセキュリティ連載「半径300メートルのIT」でも取り上げたことから、記憶に残っている読者もいるのではないだろうか。 インシデントのあらましを簡単に説明しよう。これは、コインチェックが利用する外部のドメイン登録サービスにおいて、コインチェックのネームサーバ(DNS)情報が、何者かに書き換えられたものだ。これにより、同社のドメインのレコードが偽のDNSに登録され、同社にメールで問い合わせた顧客のメールアドレスと本文が第三者に流出する可能性があった。コインチェックはインシデント発生後、対応についてのレポートを公開するとともに、利用するドメイン登録サービスを変更したと発表した。 このインシデントは、一般に「不正アクセス」と
セキュリティ脆弱性診断などでたまに CSRF について指摘されることがあります。 今まではトークン発行して対応すれば良いんでしょ? と思ってましたが、SPA のように非同期通信が前提の場合はどう対処するべきなんだろう、と疑問が出たりしたので、調べてみた結果をまとめてみました。 CSRFとは Cross Site Request Forgeries(クロスサイトリクエストフォージェリ)の略で、 サービス利用者の正規権限を利用して、意図しないタイミングでサービスの機能を実行させる攻撃手法のことを指します。 2005年に mixi 日記で発生した「ぼくはまちちゃん」で一躍有名になりました。 大量の「はまちちゃん」を生み出したCSRFの脆弱性とは? - ITmedia エンタープライズ CSRF が発生する原因 サービスの機能を実行するプログラムへのリクエストの検証が権限情報のみであった場合に発生
クラウドワークス SREチームの @kangaechu です。アンタッチャブルのコンビ復活に目が離せないこの頃です。 クラウドワークス Advent Calendar 2019の4日目として、最近SREチーム内で使われるようになったツール、 aws-vault を紹介します。 背景 aws-vaultの話をする前に、少しだけAssumeRoleの話をします。 AssumeRole assumeは引き受けるなどの意味を持つ単語で、AWSを使用するユーザやリソースが本来持っている権限とは別の権限を引き受けることができるしくみです。ものすごいざっくりいうと、sudoコマンドのような感じです。AssumeRoleはどのようなときに便利なのでしょうか。 マルチアカウントでのIAMユーザ集約管理 リソースの分離や課金管理などを目的として、最近はAWS Organizationsを使用したマルチアカウン
コンテナイメージのレジストリでは、脆弱性検査の実装が当たり前になっている。企業でKubernetesなどコンテナを使用するにあたって脆弱性対策がどれほど重要なものか理解するために、脆弱性検査や、関連する国際的な標準について整理した。 脆弱性(ぜいじゃくせい)とは 脆弱性とは、プログラムの動作の不備を悪用される情報セキュリティ上の弱点である。つまり、ソフトウェア上の問題が原因となって生じた欠陥であり、セキュリティホールとも呼ばれる。当然、ソフトウェア開発者は、脆弱性を産まないように細心の注意を払ってコード開発を進めるが、開発者が利用するオペレーティングシステムのライブラリやパッケージに含まれることもある。そのような事情から、開発者の責任範囲外に原因がある場合も多くある。 潜在的な脆弱性を突いた新たなクラッキングの手口が、時間の経過ともに発見される。そのことから、開発当初はコードに脆弱性は無い
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Randall Degges - Please Stop Using Local Storage 原文公開日: 2018/01/26 著者: Randall Degges 日本語タイトルは内容に即したものにしました。 画像は元記事からの引用です。 初版公開: 2019/10/19 追記更新: 2024/04/05 -- リンク情報を記事末尾に移動しました 本気で申し上げます。local storageを使わないでください。 local storageにセッション情報を保存する開発者がこれほど多い理由について、私にはさっぱり見当がつきません。しかしどんな理由であれ、その手法は地上から消えてなくなってもらう必要がありますが、明らかに手に負えなくなりつつあります。 私は毎日のように、重要なユーザー情報をlocal storageに保存す
サマリ PHPサーバーサイドプログラミングパーフェクトマスターには、PHP入門書としては珍しくクロスサイト・リクエストフォージェリ(CSRF)対策についての説明があるが、その方法には問題がある。アルゴリズムとして問題があることに加えて、実装上の問題があり、そのままコピペして用いると脆弱性となる。 はじめに 古庄親方の以下のツイートを見て驚きました。 CSRF用のトークンの作成 $token = password_hash(mt_rand(), PASSWORD_DEFAULT); ってのを書籍で見た………もンのすンげぇなぁ(苦笑 書籍名でググって調べる……評判が悪いので、まぁ、納得っちゃぁ納得。 — がる (@gallu) July 17, 2019 CSRFトークンの生成に、password_hash関数を使うですと? 親方に書籍名を教えていただき、購入したのが、この記事で紹介する「PH
2019.04.05 セキュリティ: 3月26日のbootstrap-sass gem 3.2.0.3に危険なコードが含まれていた(影響を受けるサイトは少ない可能性) 訂正(2019/04/05): タイトル後半を「影響は小さい可能性」->「影響を受けるサイトは少ない可能性」に修正しました。また、「はじめに」のパラグラフを修正・追記いたしました🙇。 はじめに 3月26日に公開されていたbootstrap-sass gem 3.2.0.3に危険なコードが含まれていたという情報を記事にしました。 公開されていた期間が短かったこともあり、直接の影響範囲は小さい直接影響を受けるサイトは少ない可能性がありますが、取り込んでしまった場合の脆弱性が大きいため、最近bundle updateを行った方などは一度チェックしてみるとよいでしょう。詳しくは以下の元記事Bなどをご覧いただくようお願いします。 本
株式会社クリアコード > ククログ > Webアプリや拡張機能(アドオン)で、Web Crypto APIを使ってローカルに保存されるデータを暗号化する ※注記:本文末尾の「公開鍵暗号ではなく共通鍵暗号を使う理由」の説明について、2019年1月30日午前0時から21時までの間の初出時に内容の誤りがありました。また、2019年1月30日午前0時から2月5日20時頃までの間において、本文中での AES-CTR による暗号化処理が、 nonce を適切に指定していないために脆弱な状態となっていました。お詫びして訂正致します。初出時の内容のみをご覧になっていた方は、お手数ですが訂正後の説明を改めてご参照下さい。 クリアコードで主にMozilla製品のサポート業務に従事している、結城です。 FirefoxやThunderbirdがSSL/TLSで通信する際は、通信内容は自動的に暗号化されます。その一
AngularJS への改宗が完了した「mitsuruog」です。 AngularJS に限らず Single page application(以下、SPA)を構築した場合、認証(Authenticate)とその後の WebAPI での証明情報(Credential)の受け渡し方法について最近悩んでいます。 調べていたら Json Web Token(以下、JWT)を利用した方法がCookies vs Tokens. Getting auth right with Angular.JSで紹介されていて、試してみると結構使えそうでしたので紹介してみます。 目次 1.WebAPI での証明情報の受け渡しの重要性 2.Token を利用した証明情報の受け渡し 3.実現するためのコア技術、JWT(Json Web Token)とは 4.Token を利用した場合の課題など 秘密鍵の管理 リフレッ
Collected, curated and written by: Yoni Goldberg, Kyle Martin and Bruno Scheufler Tech reviewer: Liran Tal ( Node.js Security Working Group) Welcome to our comprehensive list of Node.js security best practices which summarizes and curates the top ranked articles and blog posts Few words before we startWeb attacks explode these days as security comes to the front of the stage. We’ve compiled over 2
クリックして拡大画像表示 図1(Approved SIGINT Partners)NSAの信号諜報(SIGINT: Signals Intelligenceの略)協力国についてのNSA機密文書。最も緊密に情報を共有する「Second Parties」が英語圏の国々で、別名「ファイブ・アイズ」。日本は協力国ではあるが、監視対象ともなる「Third Parties」に含まれている。 標的は政府機関だけではない ターゲット・トーキョーの盗聴経路はわかっていないが、NSAが国際海底ケーブルへの侵入、衛星通信の傍受、マイクロソフト、グーグル、フェイスブックなどインターネット各社への要請によって、世界中のコミュニケーションの「コレクト・イット・オール」(すべて収集する)を目指していることは、スノーデンの公表した機密文書によって明らかになっている。(↓図2参照) クリックして拡大画像表示 図2(Coll
夏休みに考えたいセキュリティの話です。 ここ数年、普及期を迎えているDockerですが、細かく突っ込んでみると危ない部分があったので、知見を共有するとともに対策を紹介します。 セキュリティが緩いDockerブリッジネットワーク Dockerには複数種の仮想ネットワークを作成する機能があり、「ブリッジネットワーク」はその中でも最もよく使われる仮想ネットワークです。 オプションなしでコンテナを起動すると、コンテナは「bridge(docker0)」というブリッジネットワークに接続され、コンテナ間の通信や外部通信はそこを通して行われます。 また、最新のDockerでサポートされたswarm modeを使う場合、コンテナには「ingress」というコンテナ内で立ち上げたサーバのポートを外部公開するための特殊ネットワークと、「docker_gwbridge」というインターネットアクセスを提供するブリ
.app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads
光の速さのWEBサーバー(nginx)をlet's encryptでSSL化及びHTTP/2化。ついでにセキュリティ評価をA+にする。nginxCentOSSSLTLSLet’sEncrypt 前回のおさらい インフラ さくらのVPS(v4) SSD 1G CentOS7.2 (OS) ミドルウェア nginx 1.8.0 php7.0-fpm (アプリケーション) MariaDB(SQL) 5.5.44 フロントエンド Wordpress 4.4.1 前回の記事の通り、Ansibleであっという間に以上の構成のwebサーバーを組むことができました。今回の記事ではこれらを無料で証明書を発行するwebサービス、let's encryptを使ってSSL/TLS化しちゃいます。そして、ついでにSSLの評価計測サイトであるQualys SSL Reportのセキュリティ評価でA+をもらっちゃいます
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く