昨今GitHub上で提供されている有名なOSSに対して攻撃がなされることが多い（例: Nxの2025/08の事例）。自分もそこから学び、最低限GitHub上でセキュリティ周りの設定を入れた方が良いと考えた。 設定を考えるにあたって、とくに次の3つの記事が参考になった。 リポジトリを保護するためのクイック スタート - GitHub ドキュメント Nx の攻撃から学べること #s1ngularity | blog.jxck.io GitHub の Immutable Releases を有効にしてセキュリティインシデントを防ごう これらを参考にAIと協力して最低限のセットアップドキュメントを作ったので共有する。もっとこういう設定を入れるべきなどあれば、教えてもらえると嬉しい。 GitHub OSS セキュリティ最低限セット チェックリスト [ ] Dependabot Alertsを有効化
「安全なウェブサイトの作り方」は、IPAが届出(*1)を受けた脆弱性関連情報を基に、届出件数の多かった脆弱性や攻撃による影響度が大きい脆弱性を取り上げ、ウェブサイト開発者や運営者が適切なセキュリティを考慮したウェブサイトを作成するための資料です。 「安全なウェブサイトの作り方」改訂第7版の内容 第1章では、「ウェブアプリケーションのセキュリティ実装」として、SQLインジェクション 、OSコマンド・インジェクション やクロスサイト・スクリプティング 等11種類の脆弱性を取り上げ、それぞれの脆弱性で発生しうる脅威や特に注意が必要なウェブサイトの特徴等を解説し、脆弱性の原因そのものをなくす根本的な解決策、攻撃による影響の低減を期待できる対策を示しています。 第2章では、「ウェブサイトの安全性向上のための取り組み」として、ウェブサーバの運用に関する対策やウェブサイトにおけるパスワードの取扱いに関す
この記事は、ナウキャスト Advent Calendar 2025の21日目の記事です。 イントロダクション：エンタープライズがMCPを必要とする理由 たとえば、こんな業務フローを想像してください。 まずはJiraで「今日やるべきタスク」を洗い出す タスクに紐づく仕様や背景をNotionのドキュメントから確認する 影響範囲や次のアクションをSlackに共有する そのままJiraのチケットを更新・完了して、次へ進む 本来ならブラウザのタブを行ったり来たりしながら、検索し、コピペし、文脈を整え、最後に状態を更新する――という“人間がつなぎ役”になる作業が必要です。 ところが2025年は、この一連の流れが（まだ荒削りではあるものの）ClaudeのようなMCP対応クライアントを中心に、すでに動き始めています。Atlassian（Jira/Confluence）、Notion、Linear、Slac
はじめに Web開発やインフラに関わっていると、必ず目にするのがHTTPSです。 今や「HTTPではなくHTTPSが当たり前」という世界になっています。 一方で、こんな経験はありませんか？ 証明書エラーが出たけど、よく分からず無視した 「オレオレ証明書」と言われてもピンとこない HTTPSなのに「安全ではありません」と表示されて混乱した SSL/TLSは使うことは簡単ですが、何が起きているかを理解するのは意外と難しい技術です。 特に新人エンジニアのうちは、 「HTTPS ＝ 暗号化されていて安全」 というイメージだけで通り過ぎてしまいがちです。 しかし実際の SSL/TLS は、暗号化だけでなく「相手が本物かどうか」を確認する仕組みでもあります。 この記事で扱うこと・扱わないこと この記事では、SSL/TLS を 次の視点 から説明します。 TLSは何を守っているのか サーバーはどうやって
About ME 生まれたて０歳ベンチャーで、コーポレート何でも屋さんをしている相澤です。 法人営業から事業開発を経て、前職で情シスの立ち上げを経験。まだまだ情シス２年生。 気がついたら何でも屋になっているのは情シスあるあるだと思いますが、私は何でも屋が情シスに収まったパターンです笑 はじめに 今回は、ISMS取得の備忘録です。 が、せっかくなので これからISMSを取ろうと思っている方の参考になるよう、できるだけ詳しく記していきます。 「ここもっと教えて！」をいただければ解説・追記するので、ご連絡・ご相談もお待ちしております💁♂️ ⚠️注意⚠️ 本記事は、あくまで私の取得経験に基づく情報です。 審査機関による違いや、規格変更に伴う差分が発生する可能性がありますので、ご了承ください。 What：ISMSとは 某GPT曰く ISMSとは、Information Security Mana
【告知】2022年6月20日(月) 18時よりTwitterスペースで座談会「セキュリティチェックシートをなんとかしよう！@SAJ」を開催しました。SAJ会長でもある、さくらインターネット田中社長に加え、Assured大森さん、Conoris井上さんも参加。録音したものを聞けますのでどうぞ！ はじめに ソフトウェア協会（SAJ）で筆頭副会長を務めている青野慶久と申します。普段はサイボウズ社の代表をしています。 この度、IT業界で慣習となっている「セキュリティチェックシート」について、問題提起と課題の提案をさせていただきます。 概要「セキュリティチェックシート」とは、ITサービスのリスクを評価するために使われるチェック表です。 例えば、ある企業でクラウドサービスを導入するとき、提供者（ベンダー）のサービスが自社のセキュリティ基準に合致しているかどうかを確認（リスクを評価）するために、自社で作
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
エージェンシー事業でリードデータエンジニアを行なっている大窄 直樹 (おおさこ)です. AWSのログ, サーバーのログってたくさん種類があって難しいですよね... 同じようなログがたくさんあるので, 何を取れば良いのかとか どのくらいの期間保持すれば良いのかとか またその後の, ログの実装や, 分析方法する方法も難しいですよね... 今回AWSに構築した商用アプリケーションのログを整備する機会があったので, このことについて書こうかなと思います. 概要 本題に入る前の準備 今回ログ実装するアーキテクチャ ログに関する法令 ログの取得箇所 設計 保管するログの決定 インフラのログ OSのログ アプリケーションのログ ログの保管 保管場所について 保管期間について バケット構造 アプリケーション, OSのログの転送 実装 アプリケーション, OSのログをfluentbitを用いてS3にログ転送
pictBLandとpictSQUAREに対する不正アクセスがあり、パスワードがソルトなしのMD5ハッシュで保存されていたことが話題になっています。 2023年8月16日に外部のフォーラムにpictSQUAREより窃取した情報と主張するデータ販売の取引を持ち掛ける投稿が行われた（中略）パスワードはMD5によるハッシュ化は行われているもののソルト付与は行われていなかったため、単純なパスワードが使用されていた29万4512件は元の文字列が判明していると投稿。（それ以外の26万8172件はまだMD5ハッシュ化されたままと説明。） 不正アクセスによるpictBLand、pictSQUAREの情報流出の可能性についてまとめてみた - piyolog より引用 これに関連してMD5ハッシュやソルトに関するツイート(post)を観察したところ、どうもソルトの理解が間違っている方が多いような気がしました。
みなさま、認可の設計に苦しんでいるでしょうか？私は苦しんでいます。苦しまなかった瞬間などありません。昔「アプリケーションにおける権限設計の課題」を執筆しましたが、あれから3年以上が経ちます。 当時は認可の設計に関する情報がうまくまとまっている記事などほとんど無く、調べに調べて得たナレッジを書き記したのが上記の記事です。3年以上経ちますが、苦悩が今も特に変わっていないことが驚きです。 ただし、世の中的には認可のライブラリであったりサービスというのは少しずつ増えてきている印象があります(Auth0の OpenFGA であったりOsoの Oso Cloud 、Asertoの Topaz )。 認可の設計に関する記事も少しずつ増えている印象があり、その中でも本記事で紹介したいのがAuthorization Academyです。 これは認可サービスである Oso Cloud やOSSのライブラリ o
年間1000人以上。 警察に行方不明者届が出された子供の人数です。 今、子供の見守りを技術面でサポートする動きが始まっています。 毎年1000人以上が行方不明 令和3年は1010人。 人口10万人あたりでみると10人から12人にのぼります。 警察庁によると、9歳以下の子供の場合、迷子や家出などのケースが多いそうで、ほとんどのケースは無事に見つかっているといいます。 ただ、警察に届け出を出すほど、子供がいなくなって不安に思う人がたくさんいるのは事実です。 実際に、犯罪や事故に巻き込まれた可能性があるとして、警察が公開捜査に踏み切るケースもあります。
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ゴールデンウィークのはじめ（4月29日）に投稿された以下のツイートですが、5月7日20時において、1,938.8万件の表示ということで、非常に注目されていることが分かります。 我が名はアシタカ！スタバのFreeWi-Fiを使いながら会社の機密情報を扱う仕事をしてたら全部抜かれた。どうすればよい！ pic.twitter.com/e26L1Bj32Z — スタバでMacを開くエンジニア (@MacopeninSUTABA) April 29, 2023 これに対して、私は以下のようにツイートしましたが、 これ入社試験の問題にしようかな。『
“究極の半導体”と注目のダイヤモンド。「熱への強さ」「高い電圧に耐える力」からＥＶ軽量化や６Ｇ通信などへの応用が期待される。開発の最前線と実用化への課題を考える
1Passwordを使って、ローカルにファイル(~/.configや.env)として置かれてる生のパスワードなどを削除した 最近、コミットはされないがローカルのディレクトリに置かれている.envのようなファイルから生のパスワードやAPI Tokenを削除しました。 これは、ローカルでマルウェアを実行した場合に、ローカルに置かれている生のパスワードやAPI Tokenを盗まれる可能性があるためです。 最近は、npm install時のpostinstallでのデータを盗むようなマルウェアを仕込んだりするソフトウェアサプライチェーン攻撃が多様化しています。 Compromised PyTorch-nightly dependency chain between December 25th and December 30th, 2022. | PyTorch What’s Really Goin
こんにちは @zaru です。今回は昔からある CSRF (クロスサイト・リクエスト・フォージェリ) の今時の対策についてまとめてみました。もし、記事中に間違いがあれば @zaru まで DM もしくはメンションをください (セキュリティの細かい部分についての理解が乏しい…) 。 2022/08/29 : 徳丸さんからフィードバック頂いた内容を反映しました。徳丸さん、ありがとうございます！ 認証あり・なしで対策方法が違う点 トークン確認方式のデメリットのクロスドメインについての言及を削除、代わりに Cookie 改変リスクを追記 Cookie 改ざん可能性について徳丸さんの動画リンクを追記 SameSite 属性で防げない具体的なケースを追記 nginx 説明が関係なかったので削除 そもそも CSRF ってなに？ 昔からインターネットをやっている方であれば「ぼくはまちちゃん」 騒動と言えば
Cross-Site Request Forgery（クロスサイトリクエストフォジェリー）って何？ 頭文字をとって「CSRF」ですが、出来るだけ平たく説明すると 「悪いヤツが作ったサイトから読み込んだHTMLやらスクリプトが、勝手に別のサイトにHTTP POSTのリクエストを送信して、知らない間にそのサイトにある自分のデータなどを変更される」 といった感じになるかな。 データの中には重要なデータもあるでしょう。Amazonで欲しい物リストがあったとして、それが全部勝手に「購入」されたら困りますよね。銀行の口座から別の口座にお金が入金されても困ります。（もちろん、Amazonや銀行のサイトなどではCSRF対策がしっかりと施されているでしょうから、大丈夫！・・っであることを祈る） Cross-site とは二つのウェブサイトを跨いでること。サイトのひとつは当然「悪いヤツのサイト」でもうひとつは
おはようございます、ritouです。 この話に乗っかっていきます。 3行で ログアウト時にJWTを無効化できない実装は今後脆弱性診断で「OWASP Top 10 2021違反」と指摘されるようになりそう(今も個別にされてるかもしれないけど) JWTは単純なフォーマットなので、ステートレスなセッション管理においてログアウトしたときに文字列自体を無効化できない件は独自エンコード方式(一般的にフレームワークのCookieストアと呼ばれているもの)でも起こり得る 「セッションID vs JWTで内包」 以外にも 「セッションIDをJWTに内包」もあり得る。既存の機能を残しつつ「JWTで武装」する選択肢も考えてみてはどうか。 ステートレスなセッション管理でログアウトの際に文字列自体を無効化できない問題 これは前から言われていますし、駆け出し何とか勢のQiita記事に書かれるぐらいには一般的です。 2
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
