AWS WAFをバイパスしてSQLインジェクション攻撃をしてみる - Soon Lazy
最近はAWS WAFを触っています。こういう防御ツールは、やはり攻撃をどれぐらい防いでくれるか気になります。AWS WAFの場合、SQLインジェクション系の脆弱性を探ってくれるsqlmapをかけたところ、攻撃をブロックしてくれたという記事があります。 記事を読んだり自分でちょっと試したりして、ちゃんとSQLインジェクション攻撃を防いでくれるんだーと思っていました。が、つい先日WAFをバイパスしてSQLインジェクション攻撃をするテクニックがあることを知りました。例えばOWASPのこのページには、そういうテクニックがいくつか紹介されています。 こうなると気になるのは、AWS WAFに対してWAFバイパスのテクニックを使うとどうなるかです。というわけで、実際に試してみました。 単純にSQLインジェクションしてみる まずは、AWS WAFがないときにSQLインジェクションができること、また、AWS
海外のAnsible Meetupではどんなトークがあるのか調べてみた - Soon Lazy
先日Ansible Meetup in Tokyoが開催されました。僕は、Serverspecのテスト作成を補助するKirbyというツールについてLTしてきました。 発表資料: Serverspecを導入したものの放置気味な人へ Kirbyチュートリアル: Ansible + Serverspec + Kirbyによるサーバの自動構築 - ks888の日記 Kirbyについて色々ご意見頂けただけでなく、他の方の発表を通してAnsibleの導入事例やTIPSを知ることができ、非常に有意義なMeetupでした。 ところで最近Twitterを見ていて知ったのですが、海外でもAnsible Meetupはたくさん開催されているんですね。Ansibleの公式ページを見る限り、2015年10月時点で80以上の地域で開かれているようです。 こうなると、他の地域ではどういうトークがあるのか気になりませんか
AnsibleがPlaybookを処理する流れを追ってみた - Soon Lazy
最近、サーバの構成管理ツールAnsibleのコードを読む機会があった。忘れる前にメモしたことをまとめておく。 このエントリでまとめること このエントリでは、Ansibleのplaybookを処理する部分の実行の流れをまとめる。playbookを一度でも書いたことのある人なら、大体分かる内容だと思う。 読んだコードは、2014年10月30日時点の開発版。次のURLを参照してソースを取得後、コミットID 7cd5b13e34270dd5be79269a0b88c8c408c18663 でチェックアウトする。ちなみにソースからの実行方法も同じURLに書いてある。（コードを貼るときはgithubへのリンクを付けるので、そちらを参照していただいてもOKです） http://docs.ansible.com/intro_installation.html#running-from-source もしお
Ansible Playbook向けのデバッガを作りました - Soon Lazy
（追記：このページの情報は若干古くなっています。Qiitaに紹介記事がありますので、参考にして下さい） Ansibleは強力な構成管理ツールですが、実環境で使ってみようとすると、うまく行かない点がいくつか出てきます。その中には、欲しいモジュールがない、同じことをシェルスクリプトで行うより実行時間が長くなる、などありますが、Playbookのデバッグに手間がかかる、というのもその一つだと思います。 Playbookのデバッグに手間がかかってしまうのには、少なくとも2つ原因があると考えています。1つは、Playbookの実行に失敗したときのエラーメッセージに、デバッグに必要な情報が全て含まれているとは限らないことです。例えば、インベントリやvarsファイルなどで定義した変数、Playbook内でregisterした変数についての情報は出力されません。もう1つは、Playbookの実行にかかる時
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
