タグ

securityとprogrammingに関するzaki1010のブックマーク (13)

  • 『例えば、PHPを避ける』以降PHPはどれだけ安全になったか

    Web API開発をするなら、ドキュメントは自動生成にしておこう!(PHPerKaigi2021) 皆さんの開発現場はAPIドキュメントの自動生成化がお済みでしょうか? このLTではCakePHP4にSwaggerを導入して、コードのアノテーションからドキュメントを自動生成するまでの流れをご紹介いたします。 ▼こんな方におすすめ ・これからWeb API開発を始める方 ・ドキュメント書くの面倒な方 ・実装とドキュメントの乖離に苦労したことがある方 昨年、社内で実施した勉強会のテーマの中で一番メンバーの反応が良かったのが「アノテーションからのドキュメント自動生成」でした。ドキュメント作成の手間を少しでも減らして、開発体験を向上させていきましょう! (LTではCakePHPをサンプルコードとして紹介いたしますが、Laravelに導入する手順も別途資料をご用意させていただく予定です。) http

    『例えば、PHPを避ける』以降PHPはどれだけ安全になったか
  • 「10日でおぼえるPHP入門教室 第4版」はセキュリティ面で高評価

    弊社社の麻布十番移転に伴い、社近くの麻布図書館を利用しています。麻布図書館は土地柄のイメージにあう瀟洒な建物で、蔵書がない場合は港区の他の図書館から取り寄せ(無料です)ができますので、よく利用しています。今回は、山田祥寛さんの「10日でおぼえるPHP入門教室 第4版 」を借りて読んでみました。一読して、書がセキュリティにもよく配慮されていることがわかりましたので、以下にご紹介したいと思います。 クロスサイトスクリプティング(XSS) 表示の際にHTMLエスケープするという原則を忠実に守っています。そのため、下記の e() という関数を定義して呼び出しています。 function e($str, $charset = 'UTF-8') { return htmlspecialchars($str, ENT_QUOTES, $charset); } その他にもXSS対策として重要な下記の

  • 第6回■異なる文字集合への変換がぜい弱性につながる

    文字集合自体は抽象的な「文字の集まり」に過ぎないので単独で問題になることはないが,異なる文字集合に変換する際には問題が発生する場合がある。文字集合が異なるということは,対応する文字が1対1対応していないので,変換先の文字集合で対応する文字がないケースや,多対1の対応が発生する可能性がある。 図1に,Unicodeからマイクロソフト標準キャラクタセットに変換する場合を例示した。マイクロソフト標準キャラクタセットには「骶」(尾てい骨の“てい”)や,ハングルなどはない。また,バックスラッシュ「\」(U+005C)と円記号「\」(U+00A5)がともにJIS X 0201の「\」(0x5C)に変換される場合について示している。 「漢」のように1対1対応している文字は問題ない。ハングルや「骶」のように対応するコードポイントがない場合はエラーになるか文字化けする。インターネットで「尾 骨 びていこつ」

    第6回■異なる文字集合への変換がぜい弱性につながる
  • 第5回■注目される文字コードのセキュリティ問題

    今回から5回にわたって,アプリケーション全体に関する文字コードの問題と対策について説明する。文字コードがセキュリティとどう関わるのか,疑問に思うかもしれないが,Webアプリケーションで文字コードを指定可能な個所は非常に多く,しかも文字コードの選定や処理方法次第ではぜい弱性の原因になることが分かってきている(図1)。実は文字コードはWebアプリケーションのセキュリティ問題の最新の話題と言ってよい。 2008年10月に開催されたセキュリティ・イベントBlack Hat Japan 2008では,ネットエージェントの長谷川陽介氏が「趣味と実益の文字コード攻撃」と題して,文字コード問題の広範なプレゼンテーションを発表した 。そのプレゼンテーション資料が発表されている のでこの問題の詳細に関心のある方は参照されたい。ここでは,セキュアなWebアプリケーションを開発するために文字コードの問題をどのよう

    第5回■注目される文字コードのセキュリティ問題
  • 最も危険なプログラミングエラーTop 25 | スラド デベロッパー

    ストーリー by hylom 2009年01月14日 17時04分 やはりよく言われている問題が多い、 部門より CWEとSANSが共同で「最も危険なプログラミングエラーTop 25」を取りまとめ、発表した。 このリストはSymantecやMicrosoft、米国国土安全保障省の国家サイバーセキュリティ部門、また日の情報処理推進機構(IPA)など、国際的かつ多岐に渡る組織の協力を得て作成された。パフォーマンス上の問題やセキュリティ上の脆弱性、またサイバー犯罪の原因となり得るプログラミングエラーのうち、特に頻度と危険性の高いとされるものが25点挙げられている。 エラーは大きく「コンポーネント間のコネクションが適切に保護されていない」「危険なリソースマネジメント」「不備のある防衛策」の3種類に分類され、それぞれのエラーには簡単な説明と対処法などが記述されている。挙げられているエラーは「入力デ

    zaki1010
    zaki1010 2009/01/14
    コメントに和訳あり。
  • PHPでのセキュリティ対策についてのメモ - Liner Note

  • PPDGen : 疑似個人情報ジェネレータ

    PPDGen:疑似個人情報ジェネレータは、テストデータ生成・管理ツールです。 物の個人情報にそっくりな架空の個人情報『疑似個人情報』を生成するだけでなく、 実際の個人情報(番データ)を読み込んで、住所や氏名を置き換え、安全なデータに変換することもできます。 PPDGen:疑似個人情報ジェネレータはフリーソフトです。 無料・無制限でお使いいただけます。 疑似個人情報の例 疑似個人情報とは、物そっくりながら架空の個人情報です。 姓名、住所、電話番号、生年月日、銀行口座番号、クレジットカード番号などの項目があります。 システム開発において、物の個人情報をテストに使うと、個人情報が漏洩する危険性があります。 特に、Winnyなどのファイル共有ソフトによる漏洩は、システム開発を受託した開発会社の社員が テストデータを自宅に持ち帰ることで多く発生しています。 物の個人情報の代わりに、疑似個人

    zaki1010
    zaki1010 2008/11/26
    『統計データを基に、本物の個人情報そっくりに生成した疑似個人情報』
  • まちがった自動ログイン処理

    (Last Updated On: 2018年8月20日)問題:まちがった自動ログイン処理の解答です。このブログエントリは最近作られたアプリケーションでは「問題」にしたような実装は行われていないはず、と期待していたのですがあっさり期待を破られたのでブログに書きました。このブログの方が詳しく書いていますけが「Webアプリセキュリティ対策入門」にも正しい自動ログイン処理を書いています。 参考:自動ログイン以外に2要素認証も重要です。「今すぐできる、Webサイトへの2要素認証導入」こちらもどうぞ。HMACを利用した安全なAPIキーの送受信も参考にどうぞ。 間違った自動ログイン処理の問題点 まず間違った自動ログイン処理を実装しているコードの基的な問題点を一つ一つ順番にリストアップします。 クッキーにランダム文字列以外の値を設定している クッキーにユーザ名が保存されている クッキーにパスワードが保

    まちがった自動ログイン処理
  • ブログが続かないわけ | ログイン処理が簡単と言い切れるか 〜 フィッシング対策も忘れずに

    ブログが続かないわけ | ログイン処理が簡単と言い切れるか 〜 フィッシング対策も忘れずに
  • Webアプリケーションを作る前に知るべき10の脆弱性 ― @IT

    Webアプリケーションが攻撃者に付け込まれる脆弱性の多くは、設計者や開発者のレベルで排除することができます。実装に忙しい方も、最近よく狙われる脆弱性のトップ10を知ることで手っ取り早く概要を知り、開発の際にその存在を意識してセキュアなWebアプリケーションにしていただければ幸いです。 Webの世界を脅かす脆弱性を順位付け OWASP(Open Web Application Security Project)は、主にWebアプリケーションのセキュリティ向上を目的としたコミュニティで、そこでの調査や開発の成果物を誰でも利用できるように公開しています。 その中の「OWASP Top Ten Project」というプロジェクトでは、年に1回Webアプリケーションの脆弱性トップ10を掲載しています。2004年版は日語を含む各国語版が提供されていますが、2007年版は現在のところ英語版のみが提供さ

    Webアプリケーションを作る前に知るべき10の脆弱性 ― @IT
  • T.Teradaの日記 - ログイン直後のレスポンスの返し方

    多くの会員制Webサイトでは、ID/PWによるログイン処理がある。ユーザにログイン画面を提示し、ユーザがフォームにID/PWを入力してsubmitする。ID/PWがOKであれば、ユーザのブラウザにはログイン後の画面が表示される。 以下に、これを実現するための2通りのシーケンス図を描く。セキュリティの観点で望ましいのはA、Bのどちらだろう?というのが今回のテーマ。 Aではログイン要求に対してHTTPステータス200応答とともにログイン後画面をブラウザに返している。Bではログイン要求に302応答を返して(HTTP1.1では303応答)、ログイン後画面にリダイレクトしている。 結論を言うと、セキュリティの観点では、私はBの方が望ましいと考えている。 逆に言うと、Aにはどうにも気に入らないところがある。それは、ID/PWを含むリクエストに対して200応答を返していることだ。200応答のページは、ブ

  • セキュリティアカデメイア

    4月の応募数は829件で、当選数は26件です。 当選したものは今月の抽選とは言い切れないので、単純に当選率を計れませんが、あえて計算すると3.1%になります。 3月に続けて高確率を維持しています。3%超ならかなり割がよ ...

    セキュリティアカデメイア
  • IPA セキュア・プログラミング講座 「Webアプリケーション編」に「Web関連技術」を追加

    ページの情報は、2016年10月時点のものです。2023年10月に再構成をいたしました。 なお、内容に変更はありません。 2016年10月版 2002年2月に「Webプログラマコース」と「製品プログラマコース」、2007年の6月に「Webアプリケーション編」、9月に「C/C++編」と分けて公開してきた講座のうち、原則を中心として共通的なものをまとめて2016年10月に再編しました。 なお、資料内の参照先はすべてサイトリニューアル前のURLであるため、リダイレクトを設定しています。 セキュア・プログラミング講座(2016年10月版/2017年6月一部修正)(PDF:2.3 MB) 2007年版 「ソースコード検査技術の脆弱性検出能力向上のための研究」(注釈1)を実施した一環として取りまとめた内容を、2002年から公開していたセキュア・プログラミング講座(旧版)の改訂版(2007年版)として

    IPA セキュア・プログラミング講座 「Webアプリケーション編」に「Web関連技術」を追加
  • 1