タグ

ProgrammingとSecurityに関するagwのブックマーク (15)

  • StackOverflowからのコピペをやめろ。今すぐにだ。 - Qiita

    Original article:https://dev.to/dotnetsafer/rip-copy-and-paste-from-stackoverflow-trojan-source-solution-4p8f その昔コピペできない文章というものがありました。 実際は単にフォントを変えているだけというものですが、人間の目に見える文字と実際の文字が異なることを利用した攻撃の一種と見ることもできます。 さて、最近になって似たような攻撃に関する論文が公開されました。 人間には見えない文字を織り交ぜることによって、一見問題ないコードが実は脆弱になってしまうというものです。 ただ論文は堅苦しいうえに長くて読むのがつらいので、具体的に何がどうなのかよくわかりません。 平易に解説している記事があったので紹介してみます。 以下はDotnetsafer( Twitter / GitHub / Web

    StackOverflowからのコピペをやめろ。今すぐにだ。 - Qiita
  • Inside the code: How the Log4Shell exploit works

    Products & ServicesSecurity OperationsThreat ResearchAI ResearchNaked SecuritySophos Life The critical vulnerability in Apache’s  Log4j Java-based logging utility (CVE-2021-44228) has been called the “most critical vulnerability of the last decade.”  Also known as Log4Shell, the flaw  has forced the developers of many software products to push out updates or mitigations to customers. And Log4j’s m

    Inside the code: How the Log4Shell exploit works
  • 競技プログラマーからセキュリティエンジニアになった話 | Recruit Tech Blog

    はじめに このエントリは全5回を予定する19卒新人ブログリレーの第1回目です。 はじめまして、リクルートテクノロジーズ新卒二年目の藤原 巧と申します。 私は、競技プログラミングを強みとして入社し、現在はプラットフォームセキュリティグループという部署でセキュリティエンジニアとして活動しています。 競技プログラミングといえば、プログラムの高速化が得意といった、セキュリティとはあまり縁のないイメージを持つ方も多いと思います。 ここでは、そんな競技プログラマーの藤原がセキュリティエンジニアとして働く上で、競技プログラミングの経験がどう活きているのかについてご紹介したいと思います。 想定読者 この記事は、 競技プログラマーだけど将来のキャリアに悩んでいて、その一例を知りたい人 競技プログラマーがどんな人なのか、その一例を知りたい人 を対象に書いています。 そんな方々の参考になれば幸いです。 競技プロ

    競技プログラマーからセキュリティエンジニアになった話 | Recruit Tech Blog
  • 第4回 話題のSQLインジェクションを防ぐ

    Webサイトは,そのサイト固有のサービスを提供するための機能を備えている。ショッピング・サイトなら,商品を紹介するためのカタログ機能や,ショッピング・バスケット機能,決済機能などを備えているだろう。これらの機能を実現するアプリケーションにセキュリティ上の不具合(バグ)が残っている場合がある。これをWebアプリケーションのぜい弱性という。 バグの出方が多様であるように,Webアプリケーションのぜい弱性も多様なバリエーションがある。このうち,Webサイトの改ざんに直接結びつくぜい弱性としては以下が代表的なものとなる。 SQLインジェクション OSコマンド・インジェクション ファイル・アップロード機能のぜい弱性 これらのうち,現実に問題が数多く発生しているSQLインジェクションについて,以下で詳しく説明することにしよう。 ■SQLインジェクションによる改ざん SQLインジェクションとは,SQL

    第4回 話題のSQLインジェクションを防ぐ
  • 試訳 - コードをセキュアにする10の作法 : 404 Blog Not Found

    2008年01月05日02:45 カテゴリ翻訳/紹介Code 試訳 - コードをセキュアにする10の作法 全コーダー必読。プログラマーだけではなく法を作る人も全員。 Top 10 Secure Coding Practices - CERT Secure Coding Standards 突っ込み希望なので、いつもの「惰訳」ではなく「試訳」としました。 Enjoy -- with Care! Dan the Coder to Err -- and Fix コードをセキュアにする10の作法 (Top 10 Secure Coding Practices) 入力を検証せよ(Validate input) - 信頼なきデータソースからの入力は、全て検証するようにしましょう。適切な入力検証は、大部分のソフトウェア脆弱性を取り除きます。外部データは疑って掛かりましょう。これらにはコマンドライン引数、

    試訳 - コードをセキュアにする10の作法 : 404 Blog Not Found
  • APOPのぜい弱性で見えてきたMD5の「ご臨終」

    情報処理機構セキュリティセンターは4月,メール・サーバーの認証プロトコルの一つ「APOP」について注意を喚起した。この注意喚起は,電気通信大学の太田和夫教授のグループが,APOPで使うハッシュ関数「MD5」に新たな欠陥を発見したことに基づくもの。この欠陥は,APOPだけでなく,MD5を使う電子署名などのほかのアプリケーションの欠陥も示唆する。実際にどの程度危険なものか,技術に基づいて考えてみよう。 わからないはずのパスワードが解かれる APOPは,チャレンジ・レスポンスという方式を使って,メール・クライアントとメール・サーバーのやりとりを盗聴してもパスワードが解読できないようにする。パスワードを直接やりとりせずに,まずサーバーからクライアントに「チャレンジ・コード」という文字列を送る。クライアントはチャレンジ・コードとパスワードを連結したうえで,MD5というハッシュ関数を使ってハッシュ値を

    APOPのぜい弱性で見えてきたMD5の「ご臨終」
  • #6 IT戦士 天野 仁史/こんにちはこんにちは! Hamachiya2(中編) はまちちゃんはいかにしてXSS/CSRFを見つけるか | gihyo.jp

    小飼弾のアルファギークに逢いたい♥ #6IT戦士 天野 仁史/こんにちはこんにちは! Hamachiya2(中編) はまちちゃんはいかにしてXSS/CSRFを見つけるか 天野 仁史さん、Hamachiya2さん(はまちちゃん)との対談の中編です。 編集部注) 対談は2007年3月に行われたものです。 こんにちはこんにちは! 弾:はまちちゃんはいつ頃から「こんにちは」に興味が出てきたの? は:確かmixiを始めた2年前くらいかな。mixiってブログと違って、日記にコメントがたくさんつくのがおもしろくてハマってて。毎日見てるうちにおもしろい現象を見かけたんです。たまたま誰かが「ラーメン」ってタイトルの日記書いたんですよ。そしたらほかの人もつられて「ラーメン」って日記を書き出して、それがマイミクのマイミクまでどんどん伝染していっちゃって、その日の日記一覧が全部「ラーメン」になっち

    #6 IT戦士 天野 仁史/こんにちはこんにちは! Hamachiya2(中編) はまちちゃんはいかにしてXSS/CSRFを見つけるか | gihyo.jp
  • まだまだあるクロスサイト・スクリプティング攻撃法

    前回はクロスサイト・スクリプティングのぜい弱性を突く攻撃の対策としてのHTMLエンコードの有効性を述べた。ただ,HTMLエンコードだけではクロスサイト・スクリプティング攻撃を完全に防御することはできない。そこで今回は,HTMLエンコードで対処できないタイプのクロスサイト・スクリプティング攻撃の手口と,その対策について解説する。 HTMLエンコードで対処できない攻撃には,次のようなものがある。 タグ文字の入力を許容している場合(Webメール,ブログなど) CSS(カスケーディング・スタイルシート)の入力を許容している場合(ブログなど) 文字コードを明示していないケースでUTF-7文字コードによるクロスサイト・スクリプティング <SCRIPT>の内容を動的に生成している場合 AタグなどのURLを動的に生成している場合注) 以下では,HTMLタグやCSSの入力を許容している場合と,文字コードを明

    まだまだあるクロスサイト・スクリプティング攻撃法
  • 第1回 悪意のJavaScriptで情報が漏えい:ITpro

    Web 2.0という言葉で総称される新たなインターネット時代。Webサイトやエンドユーザーに仕掛けられる攻撃もまた,2.0と呼ぶべき進化を遂げようとしている。攻撃者はWeb 2.0の中核技術であるJavaScriptを悪用してブラウザを狙う。従来の脅威対策は全く通用しない。今この瞬間にも,エンドユーザーは個人情報を盗まれる危険にさらされている。 ブログ/SNSなどユーザー発信型のサイト,Ajax,RSS──。華やかさがクローズアップされるWeb 2.0。ところがその裏側では,エンドユーザーに情報盗難などの危険が広がっている(図1)。インターネット・バンキングやEC(電子商取引)サイトのユーザーIDやパスワード,クレジットカード番号はもちろん,企業内のシステムにアクセスするためのパスワードや,パソコンに読み込んだ機密文書データなど,対象はあらゆる情報だ。 2006年12月末,米国のセキュリテ

    第1回 悪意のJavaScriptで情報が漏えい:ITpro
  • 機密情報にJSONPでアクセスするな

    2007年6月7日 はてなブックマークのコメントをうけて、「常にJSONP、JSON、JavaScriptに機密事項を含めないように」という主張を改め、「クロスドメインアクセスの対策をとっていない状態ではJSONP、JSON、JavaScriptに機密事項を含めないように」という主張に関して記述しました。 こんにちは、SEの進地です。 今回から週単位でWebアプリケーションのセキュリティに関するエントリーを書いていこうと思います。 僕自身、日々勉強して精進というところですので、もし何らかの誤りがあれば是非ご指摘ください。 つっこみ大歓迎です。 今回取り上げるのはWeb 2.0なアプリケーションでセキュリティ面で気をつけるべきことの一つ、機密情報にJSONPでアクセスするなです。 JSON(JavaScript Object Notation)はJavaScript(ECMAScript)の

  • https://labs.cybozu.co.jp/blog/kazuho/archives/2007/01/cross-site_including.php

  • 4-2. Perl の危険な関数

    Perlには他のプログラムを起動したり,文字列で与えられた式を実行時に解釈実行する機能を持つ関数が用意されている。こうした関数に与える引数は,十分に吟味しないと,悪用されて意図しないコマンドを実行させられる。 Perlには外部プログラムとの連携機能が複数組み込まれている。Perlは連携機能を実現するため内部的にUnixシェルを起動する(注1)。そのため連携機能をユーザ入力データなどの外部から与えられるデータと組み合わせて使用する場合,外部からシェルコマンドを混入され実行されてしまう可能性がある。次の関数はこのような問題につながる注意すべき関数や構文である。 open system, exec, ``(backticks) <>(fileglob),glob C言語などのコンパイル系言語と異なりPerlはスクリプト系言語である。Perlは実行時にプログラムを解釈して実行する。eval

  • スタック・オーバーフローで任意コードを実行できるか?

    スタック・オーバーフローで任意コードを実行できるか? ~「IEに0-dayのバッファ・オーバーフロー?」の疑問に答える~ 昨日公開した記事「IEに0-dayのバッファ・オーバーフロー?」に対して、ある知人から次のような質問をされました。「スタック・オーバーフローが任意コードの実行に結びつく可能性があるとの事だが、それは一体どのような状況なのか?」といった内容です。同様の疑問を持った読者がいるかもしれません。そこで、この場を借りてお答えしたいと思います。 「絶対ない」とは書かなかった理由 前回の記事で書いたように、スタック・オーバーフローで任意コードの実行が可能になる状況は非常に限定されています。というよりも、通常はあり得ません。単に無限再帰がスタックを消費し尽くすだけであり、バッファ・オーバーフローのように、リターン・アドレス(関数からの戻り先アドレス)などの特定アドレスを書き換えられるわ

    スタック・オーバーフローで任意コードを実行できるか?
  • OBB vs AABB - Radium Software Development

    This domain may be for sale!

    agw
    agw 2006/01/18
    Utah Teapotの起源。
  • 高木浩光@自宅の日記 - ASPとかJSPとかPHPとかERBとか、逆だったらよかったのに

    ■ プログラミング解説書籍の脆弱性をどうするか 印刷されて流通する書籍に脆弱性がある、つまり掲載されているサンプルコードにズバリ脆弱性があるとか、脆弱性を産みやすいコーディングスタイルを身につけさせている解説があり、それが脆弱なプログラマを生産し続ける根源になっている問題は、「なんとかしないといけないねえ」と以前から言われてきた。 ソフトウェア製品の脆弱性は、指摘があればパッチが提供されたり修正版に差し替えられたりするが、書籍の脆弱性はどうか。正誤表が差し込まれるとか、回収する措置がとられるかというと、それは望めそうにない。言論には言論で対抗すればよいということになるだろうか。 久しぶりにいくつかの書籍について調べてみた。先月園田さんの日記などで比較的評判良く紹介されていた2冊を読んだ。 山勇, PHP実践のツボ セキュアプログラミング編, 九天社, 2004年6月 GIJOE, PHP

  • 1