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.

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 ところでこのツイートを見てほしい。このソースコードをどう思う？ 世界最悪のログイン処理コード。 実際のサービスで可動していたものだとか……https://t.co/C2bG93ZCkj pic.twitter.com/EfVNAEslrn — はっしー@海外プログラマ🇳🇿元社畜 (@hassy_nz) 2018年8月10日 すごく……セキュリティーホールです…… 一応は動いていますが、あまりに問題がありすぎるため、Twitterでも話題になっていました。 問題点は片手に入り切らないぐらいある気がしますが、一つづつ解説していきま

今日とある場所で虫が入り込む瞬間を見た。虫といってもバグの方。それはプログラマ向けの Q&A サイトで始まった。質問の内容はこうだ。 文字列には0または4がだけが含まれる。文字列は 4 から始まり、例えば 440, 44, 40, 4400, 4440 など、これらは正しいとするが 404 は正しくない。今のところ、私は 0 の直後に 4 が現れるかどうかでチェックしている。これは果たして効率的だろうか。 始め僕はこの質問文をちゃんと読んでおらず、正規表現を使ってこれを実装した。 package main import ( "regexp" ) func check(s string) bool { return regexp.MustCompile(`^4+0*$`).MatchString(s) } func main() { for _, tt := range []string{"

「不正な入力に対して脆弱性を発生させないようセキュリティ対策としてバリデーションを行う」。アホか。プログラマならセキュリティ対策とか気にするな。いや、気にするなというのは言い過ぎだけれど、ほとんどの場合においてあなたの書くコードはセキュリティ対策の必要性はない。 攻撃者の細工した入力によってSQL/HTML/JavaScriptが壊れるとかバッファオーバーフローが発生するとか、そういった脆弱性と呼ばれるほとんどのものはただのバグだ。セキュリティ対策っていうのはコードとは切り離された領域で行うDEPだったりASLRだったりX-Frame-OptionsだったりCSPだったりiframe sandboxだったり、そういうものがセキュリティ対策だ。コード上で書くのは「アプリケーションとして正しく動作するための処理」だけだ。 もちろん例外もあるかもしれないけど、それはあくまでも例外だ。日常的に書く

PHPカンファレンス2014の大垣さんと徳丸さんの対談セッション「ウェブエンジニアに必要なセキュリティスキルとは」のつぶやきをまとめました。 セッション詳細はこちら https://joind.in/talk/view/12046

C言語プログラム上で高機密性情報（パスワード文字列など）を消去するケースで、memset関数の単純利用では機密情報がメモリ上に残存してしまい、セキュリティ上の脆弱性につながる可能性がある。 void secure_operation() { // パスワード文字列を取得 char passwd[128]; get_password(passwd, sizeof(passwd)); //... // メモリ上の高機密データを消去... memset(passwd, 0, sizeof(passwd)); // ?? } 上記コードではパスワード文字列が格納された変数passwdを使用後にゼロクリアしているが、コンパイル時の最適化によりmemset関数呼び出しが削除される可能性がある。この（プログラマの意図に反する）最適化は、C言語の言語仕様上も許容されるコンパイラの振る舞いとなっている。*1

IBM Application Security Insider The IBM Application Security Insider is a blog devoted to dissecting today’s latest industry trends, observations and evolving threats in the growing web application security industry. The IBM AppScan portfolio provides web application security and compliance solutions that pinpoint vulnerabilities and helps manage the process of fixing them. Recently we discovered

このエントリでは、セキュリティの観点から、バリデーション実装について検討します。大垣さんの本を読んで「大垣流バリデーション」について勉強した結果を報告します。 はじめに 大垣さんの記事「入力バリデーションはセキュリティ対策」では、「入力バリデーションはセキュリティ対策である」が力説されています。この記事はおそらくid:ajiyoshiさんのブログ記事「妥当性とは仕様の所作 - SQLインジェクション対策とバリデーション」を受けてのことだと思います。id:ajiyoshiさんのエントリでは、「妥当性検証は仕様の問題であってセキュリティ対策ではありません」と明言されています。私はid:ajiyoshiさんに近い考えを持っていますので、大垣さんの主張について、私なりに考えてみました。 記事を書くにあたり、徳丸の立場を明確にしておきたいと思います。 バリデーションの基準は仕様の問題 バリデーション

たにぐちまことさんの書かれた『よくわかるPHPの教科書（以下、「よくわかる」）』を購入してパラパラと見ていたら、セキュリティ上の問題がかなりあることに気がつきました。そこで、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方（以下、徳丸本）」の章・節毎に照らし合わせて、「よくわかる」の脆弱性について報告します。主に、徳丸本の4章と5章を参照します。 4.2 入力処理とセキュリティ 「よくわかる」のサンプルや解説では、入力値検証はほとんどしていません。しかし、入力値検証をしていないからといって即脆弱かというとそうではありません。徳丸本でも強調しているように、入力値検証はアプリケーション要件（仕様）に沿っていることを確認するもので、セキュリティ対策が目的ではないからです。 「よくわかる」の中で、私が見た範囲で唯一の入力値検証は、郵便番号のチェックをするものです。以下に引用します（「よくわ