安全代码洞察

「タップ」と「ハイジャック」を組み合わせたタップジャックは、まさにそれを意味します。これは、攻撃者がユーザーのタップをハイジャックして、意図しないことをするように仕向ける攻撃です。では、この攻撃はどのように機能し、どのように防ぐことができるのでしょうか。

ストーリーはスクリーンオーバーレイから始めます。スクリーンオーバーレイ、またはGoogleが言うところの「TYPE_APPLICATION_OVERLAY」タイプのウィンドウ。 これらは他のアプリの上部に描画されるウィンドウで、通常は画面の一部のみが見えにくくなります。これらは、アプリが新しい権限をリクエストするときによく使用されます (下の画像の例のように)。

これは実際にはクールで楽しい機能であり、ますます多くのアプリが使用され始めています。下のスクリーンショットのように、Facebookのチャットバブルや、画面の隅にあるGoogleマップのナビゲーションについて考えてみてください。

ただし、これらのオーバーレイにはセキュリティ上のリスクが伴います。アクティブなスクリーンオーバーレイはどれもタップを聞き取ることができますが、バブルをタップまたはドラッグしたことをFacebookが知るにはどうすればよいでしょうか？これにより、アプリがユーザーをスパイし、パスワードやクレジットカードデータを盗む可能性があります。

さらに一歩進んで、タップジャックという用語の由来にもなっています。オーバーレイは、他のアプリの上に何かを描画して、ユーザーをだましてさまざまなアクションを実行させることができます。ユーザーは自分がオーバーレイを操作していると思っていますが、実際には、タップは基盤となるアプリでもアクションを実行します。こうすることで、この例のように、オーバーレイはユーザーを騙して特定の権限を有効にさせたり、危険な設定を変更させたりすることができます。 古いユーチューブの動画。

上のデモ動画は2010年にYouTubeにアップロードされたので、古いバージョンのAndroidで撮影したものです。しかし、この攻撃は今日でもなお重要であり、 脆弱性 ヌガーやマシュマロなどの新しいバージョンのAndroidでタップジャックを許可することが明らかになりました。

それで、あなたはそれについて何ができるでしょうか？ユーザーとしては、これらのオーバーレイがもたらす影響を認識し、オーバーレイを使用するアプリについて知っておくことが重要です。API レベル 23 (Android 6.0 マシュマロ) 以降、この権限は次のような権限になりました。 ユーザーによる明示的な許可が必要です。しかし、それは去ります アンドロイドの 50%ユーザーは依然として脆弱です。どのアプリがこの権限を使用しているかは、「他のアプリの上に表示する」の設定で引き続き確認できます。

開発者の責任は、ユーザーのアクションがユーザーの完全な知識と同意を得て行われるようにすることです。Android では、そのためのビュー設定として、次のような設定が用意されています。 フィルタータッチがぼやけている場合。 これを有効にすると、ビューウィンドウが別の表示ウィンドウに隠れると、フレームワークは受け取ったタッチを破棄します。それだけ簡単なので、設定してください。 不明瞭になったらタッチをフィルタする true に設定すると、アプリはタップジャッキングから安全になります。

頑張って、また来週会いましょう！

許可リクエストの付与、購入、広告のクリックなど、ユーザーの十分な知識と同意を得た上でアクションが実行されていることをアプリケーションで確認できることが不可欠な場合があります。残念なことに、悪意のあるアプリケーションが、ビューの意図された目的を隠すことで、気づかないうちにユーザーを騙してこれらのアクションを実行させようとする可能性があります。

https://developer.android.com/reference/android/view/View.html

もともとはに掲載されました DevSecCon ブログ。

私は、セキュリティ・ベスト・プラクティスを守るうえで、開発チームとアプリケーション・セキュリティ・スペシャリストの間に生じる緊張関係について、両者の立場に立ってきたことをよく知っています。

難しいことです。結局のところ、開発者の最優先事項はソフトウェア機能の提供です。美しく、機能的で、アプリケーションの力をアピールできるものでなければなりません。最近ではアジャイル開発手法が一般的に行われているため、これらの機能は厳しい期限内に完成させる必要があります。また、セキュリティが懸念事項のリストの上位にあり、他にも多くのことが危機に瀕していることはめったにありません。

セキュリティはAppSecチームの領域と見なされています。AppSecチームは、コードをスキャンして（さらに悪いことに、1行ずつ手動で確認して）、コードが安全でないか、まったく使用できないことを開発チームに報告するといううらやましいほどの仕事をしています。彼らは自分たちの良い仕事をぶち壊し、イノベーションを阻害し、一般に開発者にとって頭痛の種となる泥棒のような存在です。結局のところ、セキュリティ問題の多くは非常に単純な解決策です。「おそらく、たった1行のコードで、脆弱なバックドアを数分で強化できるでしょう。

しかし、ここに問題があります。「セキュリティ」はネガティブな体験と同義語なので、開発者は本来あるべきほど密接に関わっていないだけです。このような一行の修正は行われていません。結局のところ、AppSecの担当者は常に同じ問題に遭遇しているのです。私たちが最初にSQLインジェクションの欠陥を発見 (およびその後の修正) してから20年以上経った今でも、彼らがSQLインジェクションの欠陥を指摘しているのはかなり腹立たしいことでしょう。

これまでに行ったことは、期待していたほど効果的に機能していません。私たちは、開発者とアプリケーション・セキュリティ・スペシャリストの間の架け橋を修復することに注力し、開発者がこの分野で真のインパクトをもたらすためのツールとトレーニングを受けられるような、ポジティブなセキュリティ文化の構築に努める必要があります。

誰が知っている？私のように彼らも好きになるかもしれない！

ポジティブ・セキュリティは、アプリケーション・セキュリティを向上させる最も迅速で簡単な方法です

「シティ」と、いや、目に見えない成果については大げさではありません。これは、安全なコーディングを成功に導くための絶対不可欠な要素です。

開発者は、最初に安全なコードを書くことによって、本番環境の最初からセキュリティを向上させる鍵を握っています。ポジティブなセキュリティ文化を醸成し、開発者がアプリケーションのセキュリティにワクワクするようになれば、AppSecの領域でスキャンや手動によるコードレビューを受ける前に、一般的な脆弱性を一掃できます。

それは すでにコミットされているコードの脆弱性を修正すると、30 倍の費用がかかるしたがって、開発者の強みを生かし、関心を持ち、実際に機能するトレーニングを見つけることは、繰り返し発生する脆弱性を特定して修正するための将来のコスト削減における大きな一歩となります。

開発者に焦点を当てた積極的な取り組みは、適切なセキュリティ文化を育みます。

全員がセキュリティのベストプラクティスを理解していれば、ポジティブなセキュリティ文化は幸せで不可欠な副産物になります。

積極的でスケーラブルな開発者中心の取り組みは、適切なセキュリティ文化を育みます。開発者を勝利に導くためには、問題解決能力と創造性を備えた開発者の意欲を引き付けることが不可欠です。また、新入社員がチームのセキュリティに対する期待に迅速に対応できるようにすることも重要です。 連絡を取る 開発者のセキュリティ関係がどのように発展してきたかについての概要と、セキュリティ意識向上プログラムを組織で成功させるためのアイデアを紹介します。

コンピュータシステム上のファイルを削除するのは難しいです。お母さんも含め、誰もが以前にファイルを削除しすぎたことがあるので、ゴミ箱に残っていて元に戻せることに満足しています。

コンピュータシステムのデータは一連のビットで表されます。つまり、システムは、どのビットがどのファイルを表しているのかを知るために、ファイルシステム内で何らかの管理を行う必要があります。この情報には、ファイルのサイズ、最終更新日時、所有者、アクセス権などがあります。この簿記データはファイルの内容とは別に保存されます。

通常、ファイルが削除されても、そのファイルを表すビットには何も起こらないが、記憶域のこの部分は無意味で再利用できることをシステムが認識できるように、記録データが変更される。この場所に別のファイルが保存され、その場所のビットが上書きされるまで、保存されたデータを回復できることがよくあります。これにより、ファイルの削除速度が向上するだけでなく、削除を取り消すのに便利な機能であることがよくあります。

ただし、このアプローチには欠点があります。コンピューターシステム上のアプリケーションが機密情報を処理する場合、そのデータはファイルシステムのどこかに保存されます。ある時点で、その情報が不要になると、このデータは削除されることがあります。開発者の意図がすべてのデータを削除したとしても、特に注意を払わなければ、このデータは回復可能な場合があります。

そのデータを完全に消去する最も簡単な方法は、ファイルの内容をランダムなデータで書き換えることです (場合によっては数回繰り返すこともあります)。既存の安全なファイル削除方法はいくつかあり、それらはストレージの種類やファイルシステムによって異なります (Gutmann メソッドなど)。ただし、日常的なアプリケーションの使用では、これらは少しやり過ぎで、自分でデータを上書きするだけで済みます。

ただし、注意してください。すべてゼロやその他の低エントロピーのデータは使用しないでください。多くのファイルシステムは、このようなスパースファイルの書き込みを最適化し、元の内容の一部を残す場合があります。ファイル自体を削除する前に、安全にランダムなデータを生成してファイルの内容全体を上書きすることが推奨されます。

データ残留とは、何らかの方法で消去されたデータが物理的に残っている状態のことです。ストレージメディアを消去した後には、データを再構築できる物理特性がある場合があります。

https://fas.org/irp/nsa/rainbow/tg025-2.htm

随着网络威胁的数量不断增加，企业每天都在安全、实用性和速度之间做出权衡--在这个过程中暴露出自己的风险。需要新的安全编码方法，因此，安全 代码战士与埃文斯数据公司合作，对开发人员对安全编码的态度、安全代码实践和安全操作进行主要研究（下载白皮书 这里).

这份报告显示，虽然 "老派 "的被动思维仍占主导地位，但人们越来越意识到需要更积极的解决方案，将开发者本身变成第一道防线。  

任何关于采用安全编码实践的探索都需要从了解参与实施的人类、他们对安全编码的看法以及他们实施安全编码的能力开始。这就导致了难题中最重要的部分--如何让他们从一开始就能更安全地编码，并更快、更有信心地发送高质量的代码？ 

安全编码--我们现在在哪里，有什么需要改变？ 下载 信息图 "人的因素"，现在。

当前的观点--被动与主动

当开发人员和开发经理被问及他们与安全编码相关的活动时，前三个回答是：。

• 在已部署的应用程序上使用扫描工具。
• 手动审查代码中的漏洞。
• 编写受保护的软件的积极和持续的做法，以防止漏洞。

正如我们所看到的，前三个回答中的两个仍然集中在反应式方法上--第一个依赖于工具（扫描仪），第二个依赖于开发人员（即人类）执行手动检查。

同时，在被提名的三项活动中，有两项是依靠人的因素。这表明人们越来越认为安全是一个人的问题。但在所有被提名的活动中，最能说明问题的是第3项，它确定了在编写软件时的人为因素，首先要保护其不受漏洞影响。这突出了一个向左开始的转变--一种主动的和预防性的方法，从SDLC的一开始就将安全纳入软件。 

安全在SDLC中的位置？ 

当开发人员和开发经理被问及他们认为安全编码实践融入SDLC的地方时，意见不同。55%的经理认为安全编码被整合到了整个开发过程中，而只有43%的开发人员认为是这样。这种差异可能反映了这两个群体在SDLC中的不同角色。管理人员通常较少参与编码的实际工作，并倾向于有一个更高层次的观点 - 而开发人员可能更关心螺母和螺栓。

但从整体安全和代码质量的角度来看，令人震惊的是，只有13%的开发人员和10%的管理人员表示，安全代码实践应该被整合在设计阶段--就在SDLC的开始。这是一个巨大而未实现的机会。根据IBM的一项研究，修复发布后的代码中的漏洞要比在一开始就发现和修复这些漏洞的成本高30倍。软件安全不能仅仅依靠工具来解决，它必须考虑到人的因素。 

人的因素准备好了吗？

97%的受访开发者认为他们已经接受了足够的安全编码培训，95%的人认为安全编码培训对他们的职业生涯有价值。但在接受这些说法的表面价值之前，我们需要问：为什么代码漏洞仍然如此普遍？开发者声称的安全代码专业知识只是人类自我的一种情况吗？证据当然指向了这个方向。在更谦虚的承认中，超过88%的受访开发者承认安全编码很难学习，91%的开发经理承认安全编码实践在实施中具有挑战性。当被问及围绕安全编码实施的主要个人问题时，28%的开发人员认为学习过程具有挑战性，而24%的人认为学习过程很无聊。这指出了一个事实，即开发人员的培训需要改进。 

人的因素需要什么？ 

为了克服 "挑战 "因素，有价值的安全培训需要一个 "脚手架 "过程，支持开发人员一步步建立安全编码技能。为了获得最大的相关性和即时适用性，培训应该在他们每天使用的特定语言和框架中进行。

为了克服 "无聊 "的因素，安全代码培训需要以实践的方式进行--事实证明，这比过时的课堂或 "观看视频 "模式更能吸引开发人员。这些方式应该包括现场模拟，让开发人员在安全的环境中解决有时很危险的安全挑战。其目的应该是教导开发人员如何在工作中发现和修复代码中的漏洞，并使安全编码成为他们日常工作的一部分。另一个关键的有利因素是内部的IDE提示和辅导，这有助于开发人员在编码时不断学习和提高技能，在工作中防止和消除漏洞。

如果你想了解如何为你的开发人员提供这种以开发人员为中心的新水平的工具和培训。 预约演示现在就可以。

你还可以 下载你的副本 的白皮书《从反应到预防。应用安全的变化。

‍

毋庸置疑，网络攻击正在上升。根据Verizon 2021年数据泄露调查报告，今天的威胁形势比以往任何时候都更加危险。各种规模的组织正经历着更多的攻击，而针对他们的威胁者的复杂程度也更高。而攻击者的成功率也在急剧上升。

分析最近的攻击，有助于揭示黑客在这次对网络防御的空前突击中所使用的一些最常见的漏洞和技术。一些最流行的攻击，例如那些进入开放网络应用安全项目（OWASP）2021年十大安全风险和漏洞的攻击，涉及到窃取或以其他方式破坏证书。而根据Akamai进行的安全研究，绝大多数（近75%）直接针对API持有的凭证。

API的崛起和可能的毁灭

难怪应用编程接口（大多被称为API）在几乎每个组织的网络中都在上升。它们是大多数基于云的服务的重要组成部分，这些服务正在迅速取代大多数公司、组织和政府机构的内部资产的功能。如今，你几乎无法在没有云的情况下运行任何种类的业务或任务，特别是那些面向公众的业务。这意味着API肯定会成为支撑每个网络中相当多的服务的粘合剂。

API的神奇之处在于，它们在网络资源分配方面大多是小而不显眼的。而且它们是完全灵活的，因此它们可以被赋予执行几乎任何工作的任务。就其核心而言，API是为控制或管理一个特定程序而定制的单个软件片段。它们可以被用来执行非常具体的功能，如从主机操作系统、应用程序或服务中访问数据。

不幸的是，正是这种同样的灵活性，以及它们往往很小并被安全团队忽视的事实，使得API成为有吸引力的目标。大多数API是由开发人员设计的，具有完全的灵活性，例如，即使它们所管理的核心程序被修改或改变，它们也能继续发挥作用。而且很少有标准。几乎就像雪花一样，许多API都是独一无二的，因为它们是为特定网络上的单个程序提供特定功能而创建的。如果它们是由那些没有很好的安全意识的开发者编写的，或者他们没有特别专注于安全，那么它们可以而且很可能会有任何数量的漏洞被攻击者发现和利用。

可悲的是，这个问题很快就失控了。据Gartner称，到2022年，涉及API的漏洞将成为所有网络安全类别中最频繁的攻击载体。

攻击者想要破坏API的关键原因不是为了接管API执行的任何具体功能，而是为了窃取与之相关的凭证。API最大的问题之一，除了有很多漏洞之外，就是它们的核心功能往往被过度授权。为简单起见，大多数API在网络上有接近管理员级别的访问权限。如果攻击者获得了对一个API的控制权，他们往往可以利用其权限对网络进行更深入、更大量的入侵。而且，由于API有权限执行攻击者重定向的任何任务，他们的行动往往可以绕过传统的网络安全监控，因为API没有违反任何规则，这要归功于其访问所有区域的VIP后台许可。

如果企业不小心，他们的网络和云中的API的兴起，如果被攻击者盯上，也会带来大麻烦。

捍卫API

尽管API的情况变得很危险，但它远非无望。通过像DevSecOps这样的运动，有很大的努力帮助开发人员提高安全意识，并将安全和最佳实践引入软件创建的所有方面，从开发到测试和部署。将API安全作为培训的一部分，对于任何想在2022年及以后抵御API剥削趋势的组织来说都是至关重要的。

也就是说，在API安全方面，现在有一些真正好的最佳实践可以实施。

第一件事是为所有的API包括严格的身份控制。在分配权限时，你几乎应该把它们看成是人类用户。仅仅因为一个API被设计成只做一个特定的功能，你就必须考虑如果一个攻击者能够破坏它，会发生什么。考虑使用基于角色的访问控制。理想情况下，你最终应该对你的API和用户采用零信任原则，但这往往是一条漫长的道路。良好的身份管理是一个好的开始。只要确保将API作为该计划的一部分。

你还应该尽可能地严格控制你的API所进行的各种调用。如果你把这些调用限制在以上下文为中心的请求上，那么攻击者就很难为邪恶的目的而修改它们。你甚至可以将你的API分层，由最初的API对另一个API进行高度的上下文调用，这个API知道要寻找什么，以及要忽略什么。这可以成为一种有效的方式来限制威胁行为者可用的功能，即使他们能够利用和破坏该链中的API。

针对API的威胁当然看起来是压倒性的。但是，通过实施最佳实践，并协助和奖励那些成为安全卫士的开发人员，情况似乎不那么无望。通过良好的培训和实践，你可以建立一个强大的安全计划，即使攻击者以某种方式破坏了你的一个微小但重要的API工作母机，他们也没有什么回旋余地。

アプリケーションセキュリティの専門家として、組織のアプリケーションのサイバーセーフティを確保するのがあなたの仕事です。ただし、アプリケーションを実行するコードを書く責任はあなたにはありません。開発チーム内のエンジニアが担当します。では、セキュリティを念頭に置いてシステムを開発していることを確認するにはどうすればよいでしょうか。

ほとんどの場合、次の一部、またはすべてを実行しているはずです。

• すべてのコードにセキュリティ上の欠陥がないか確認し、開発チームに報告して修正します。
• 安全な開発ライフサイクル全体を通じて、厳格なピアレビュープロセスを実施します。
• 社内または社外のセキュリティチームによる定期的なアプリケーション評価/侵入テストを実施する。
• 脆弱性を検出するためのスキャンツールを実装します。
  

これらは優れたベストプラクティスですが、費用もかかり、病気になるたびに抗生物質を服用するのと似ています。これには高額な費用がかかるだけでなく、効能が失われ、時間が経つにつれて免疫系が弱まる可能性があります。

そもそも、開発者が出荷するコードが安全に記述されていることを実際に確認するにはどうすればよいのでしょうか。

安全なコーディングはさておき、まず人々がどのように学ぶかを考えてください。私たちのほとんどは視覚的な学習者であり、実践を通して学びます。それでも、セキュア・コード・トレーニングは「すぐに使える」アクティビティとして提供されることが多く、開発者の日常業務には関係ありません。これは、開発者が業界標準に準拠するためにセキュリティトレーニングを頻繁に受けていることを証明することを目的としており、開発者が実際にその知識を身につけること、ましてや学習プロセスを楽しむことは言うまでもありません。

人間が学ぶ傾向があるもう一つの方法は、免疫システムが学ぶのと同じように、間違いを通して学ぶことです。T細胞は、過去にどのような病原体に遭遇して根絶に成功したかを記憶しているので、将来それらから身を守ることができます。これこそまさに、開発者が果たすべき役割です。 安全です SDLC。

間違いを犯さないことを期待するのは非現実的ですが、将来セキュリティ上の脆弱性につながるコーディングパターンを認識できるように準備しておくことはできます。

これが、堅牢なピアレビュープロセスが非常に強力になる理由でもあります。ある開発者がセキュリティ上の欠陥に気づかないからといって、別の開発者が気づかないわけではなく、開発チーム全体のトレーニングが行き届いていればいるほど、脆弱性が彼らの足跡に引っかかり、本番環境には届かない可能性が高くなります。

ソフトウェアの脆弱性は病原体のようなものです

ソフトウェアの脆弱性は、対処するためには覚えておく必要があるという意味で病原体のようなものです。病原体の場合、重篤な病気やそれ以上の症状を避けるために、免疫系に何回も曝露しないといけないことが多いです。

脆弱なソフトウェアによるサイバー攻撃が成功すると、組織が深刻な機能不全に陥ったり、死滅したりする可能性があります。しかし、開発者が制御された環境で最初にソフトウェアの脆弱性に触れるようになれば、セキュアコーディングの知識とスキルを高め、定期的に実践することで、脅威に対する免疫力を高めることができます。

管理された環境で開発者をセキュリティ上の欠陥にさらす

病気から完全に身を守ることはできませんが、免疫システムを高め、できるだけ健康を維持するためにできることはあります。定期的な運動、健康的な食事、十分な睡眠などは、一般的に強い免疫システムに関連するライフスタイルの選択肢の1つです。しかし、これらすべてには少しの努力が必要であり、継続的でなければなりません。毎日ジョギングを1週間続けたり、1か月間飲酒をやめたりしても、全体的な健康状態はほとんど変わりません。また、ランニングを始めた初日に外に出て10kを走るのはお勧めできません。まず、心臓と筋肉を運動にさらす必要があります。また、自分の体と大好きな健康的な食べ物や運動のバランスが取れるようになるまで、少し実験する必要があることもわかっています。

安全なソフトウェア開発に関しても、それほど違いはありません。学習は時間をかけて実践しながら行われます。開発者がセキュアコーディングのスキルを定期的に高めるには、同じ継続的なトレーニングが必要です。言うまでもなく、ソフトウェア開発は常に進化し、適応しています。つまり、脆弱性も同様です。そのため、簡単なトレーニングコースだけでは不十分です。開発者は、潜在的な脅威に十分精通し、それらから防御するための適切な準備を整えるために、定期的なスキルアップが必要です。

開発チーム内での集団免疫の実現を目指す

1 人ですべてのセキュリティ問題を防ぐことはできません。チームにセキュリティチャンピオンがいるのは素晴らしいことですが、最善の保護を受けるには、セキュリティの脆弱性とその防止方法について学んだ人が増えれば増えるほど、組織がそれを防ぐ可能性が高まります。繰り返しになりますが、免疫系が目的に応じてさまざまな種類のT細胞を使用する方法と大差ありません。すべての開発者は、セキュリティを確保するチームの一員です。責任を取る権限を与えられ、それをうまく行い、さらには楽しんで取り組めるようになれば、結果として、開発チーム内でサイバー脅威に対する集団的免責を築くことができます。

繰り返し露出されることでセキュリティを最優先に

私たちの脳は、免疫システムが機能するのと同じような方法で学習します。ドイツの心理学者 ヘルマン・エビングハウス 記憶と学習の分野のパイオニアでした。彼は、学習は時間をかけて、複数の学習セッションを経て行われなければならないと推論しました。私たちが学校にいるとき、最初の導入後に新しい知識を身につけることは決して期待されていません。最初に情報が提示され、次にガイダンスを受けて練習し、次に自分で練習します。そして、試験に合格するほど十分に学んだ後でも、時間と労力をかけて学んだ知識を定期的に活用しなければ、すぐに情報が忘れられがちです。高校時代のフランス語を覚えていると言える人はどれくらいいますか？

では、ある日、スライドを見て、誰かがセキュリティについて話しているのを聞くだけで、出席している開発者がより安全にコーディングできるようになったとどうして信じられますか？

繰り返し発生する脆弱性のパターンから、これはまったく機能しないことがわかります。

安全な開発免疫を実現するにはどうすればよいでしょうか？

答えは私たちの本性にあります。私たちの体と心は同じように働き、問題に逆らわずに一緒に働く限り、問題に対する美しい解決策を提供します。

アプリケーションの安全性を確保するには、まず開発者に安全なコードを書くためのスキルアップから始める必要があります。そうしないと、AppSecは引き続きすべてのコードのセキュリティ欠陥の確認と、繰り返し発生する同じ脆弱性の開発チームへの報告に全時間を費やし、何も学ばずに迅速に修正することになります。そして、次のリリースに向けてもう一度やり直してください。

それでは繰り返しましょう。

開発マネージャーと協力してそれを行うと、安全なSDLCを実装し、コンプライアンスボックスのセキュリティトレーニング要件を満たすだけでなく、開発プロセスに現実的な影響を与えることができます。何よりも重要なのは、AppSecが脆弱性に繰り返し遭遇したり、開発チームに報告したりすることがなくなり、開発者が脆弱性の修正に費やす時間が減るということです。つまり、世界をより良くする素晴らしいソフトウェアの作成と改善に、より多くの時間を費やすことができるということです。

開発チームのスキルアップの準備はできていますか？さっそく進んで デモを予約 私たちと一緒に。

ソフトウェア開発以外で働く人にとっては直感に反するように思えるかもしれませんが、長年にわたってアプリケーションセキュリティに携わってきた専門家の多くは、プログラミングの経験がほとんどまたはまったくないまま、これらの重要な役割を担ってきました。これらのアプリケーション・セキュリティ・プロフェッショナルは、多くの業界や組織の生命線となっているアプリケーションに脆弱性が忍び寄らないようにする責任を負うチームの一員ですが、実際に自分でコードを直接評価したり修正したりできる人はほとんどいません。

多くのセキュリティプロフェッショナルは、コーディングのバックグラウンドではなく、攻撃ベクトル、脅威、エクスプロイト、ビジネスリスクに関する重要な知識の観点から自分の役割に取り組んでいます。コードに対する見方は限られています。AppSecの達人全員が同じスキルセットを持っているわけではありませんが、多くの人は通常、コードレビュー担当者やスキャンツールと協力して、プログラムやシステムが組織の標準や関連する業界や政府の枠組みに従って保護されていることを確認しています。その後、調査結果に関するレポートを作成し、コードを破壊する可能性のある攻撃ベクトルに関する情報を送り返します。そうすれば、現在の作業にどんなに支障をきたすとしても、必要な修正を行うのは開発者次第です。

このような状況になった理由は、ネットワークとアプリケーションを保護する仕事が非常に大きいため、サイバーセキュリティに携わるすべての人がすべての役割を果たすことを期待するのは意味がないというのが長年の論理でした。深いコーディングスキルは開発者に任され、開発パイプラインのさらに下位でコードを記述したり編集したりできることはほとんど重視されませんでした。

その考え方は急速に変化しており、開発者がAppSecに有利なキャリアシフトやキャリアシフトを行うまたとない機会となっています。すべての開発者がいわゆるダークサイドを受け入れたがるわけではなく、多くの開発者はアプリケーションセキュリティチームについて特に前向きな意見を持っていません。しかし、そうする人にとっては、ますます魅力的になる真鍮の指輪を手に入れるのに今ほど良い時期はありません。

DevSecOps はほぼすべての業界を牽引しています

どの組織においても、セキュリティ意識の高いプログラマーや開発者の価値を高める最大の要因の1つは、よりアジャイルな開発手法を採用する動きがほぼ普遍的に行われていることです。 DevSecOps など。開発、セキュリティ、運用が組み合わさると、サイバーセキュリティは新しいソフトウェアの開発に端から端まで組み込まれる共通の責任となります。このような環境では、コーディング能力が全体的に貴重な資産と見なされるようになってきており、セキュリティを本質的に理解しているエンジニアにとっては特にそうです。

サイバーセキュリティを高いレベルで理解しているだけでなく、すべてを機能させるコードも理解しているAppSecプロフェッショナルは、理論的な知識に集中している人よりも、どの組織にとっても本質的に価値があります。コード内に見つかった脆弱性を迅速に発見して評価し、それらの問題を軽減できることが、DevSecOpsがこれほど人気を集めている理由の核心です。

AppSecで働く開発者は、彼らを雇用するあらゆる組織にとってもう一つの大きな利点でもあります。社内の開発側から来ているため、開発者はセキュリティや脆弱性について開発者と話しやすくなります。また、開発チームのコーチになるのがずっと簡単になり、開発チームがより優れたコーダーになるのに役立ちます。時間が経てば、AppSecの「ダークサイド」という汚名を取り除き、組織全体のソフトウェア開発チームを一つにまとめる助けにもなるかもしれません。

サイバーセキュリティのスキル不足は悪化の一途をたどっています

シェイクスピアは、それは誰にも何の役にも立たない悪風だと黙想しました。彼が言いたかったのは、どんなに暗い状況でもおそらく誰かに利益をもたらすということでした。サイバーセキュリティのスキル不足はその好例です。

人員不足はほとんどどこでも深刻に感じられています。で 最近の調査 戦略国際問題研究センターが実施した調査では、ITの意思決定者の 82% が、組織がサイバーセキュリティスキルの不足に苦しんでいると答え、71% が、その不足が組織に直接かつ測定可能な損害をもたらしたと回答しました。この危機をさらに詳しく見ると、報告書は、米国だけでも、2020年には約94万人しか雇用されていない分野で、サイバーセキュリティの求人が52万件以上空いていたと指摘しています。

サイバーセキュリティ人材の不足は、ますます危険になる脅威環境からインフラストラクチャ、ビジネス、データを保護しようとしている組織にとって悪いニュースです。しかし、アプリケーションセキュリティとセキュリティに参入しようとしている開発者にとっては良い機会となります。サイバーセキュリティとアプリケーションセキュリティに関する職種は、ほとんどどこでも募集されている可能性があります。また、サイバーセキュリティの職種は平均して 21% 時間の増加 最近は給料がずいぶん上がってきています

アプリケーション・セキュリティへの移行

開発者にとって、日当たりの良いセキュリティ分野に有利なジャンプをするのに今が絶好のタイミングかもしれません。セキュリティ意識の高い開発者は、もはや暫定的なセキュリティ手法の一部ではなく、サイバーセキュリティの防御者として、全面的かつ尊敬される役割を果たしています。これは特に、DevSecOps やその他のよりアジャイルな開発方法論を採用している組織に当てはまります。また、サイバーセキュリティの人材が不足しているということは、ほぼすべての企業、政府機関、組織でポジションが空いているということです。適切なスキルを持っている人は、働きたい場所を選ぶことができます。

AppSecへの移行はすべての人に適しているわけではありません。もちろん、ほとんどの開発者は素晴らしい機能の構築に引き続き注力するでしょう。しかし、移行を検討している人にとっては、セキュリティ・トレーニングに投資して既存のコーディング・スキルを強化することで、多くの可能性が開ける可能性があります。最高のアプリケーション・セキュリティ人材は、テクノロジーを深く理解し、仲間の開発者の窮状に共感しているため、エンジニアリングの分野で活躍しています。DevSecOpsということは、今や誰もがセキュリティの責任を負っていることを意味します。現在の重要なスキル不足を利用して、アプリケーション・セキュリティ分野でキャリアを積んでみませんか？あなた自身、家族、そしてキャリアのために前向きな動きをするのに今ほど良い時期はありません。

侧信道攻击是指黑客可以从软件系统的物理实现中收集信息，而不是从算法的理论弱点或软件代码的错误中收集信息。

我喜欢用一个例子来更清楚地说明这一点，就是一个做用户名枚举的方法。如果你想知道什么是用户名枚举，或者为什么它是坏的，请访问我们的网站获取视频解释，或者玩一个挑战，看看你是否能在代码中识别它。

现在，为了理解如何通过侧面渠道攻击进行用户名枚举，你需要对现代网络应用中如何处理密码（或至少应该如此）有一些了解。一个好的网络应用程序不知道你的密码，它不会把你的密码保存或储存在任何地方。那么，它怎么知道你输入的是正确的，而且是你的密码呢？嗯，你的密码是散列的。

散列函数是一种数学运算，它很容易以一种方式进行（尽管计算上有些昂贵），但很难逆转，对于好的散列算法，输出是唯一的，取决于输入。当你在一个网站上注册时，该散列值被安全地存储，而不是你的密码本身。这意味着，每次你登录时，网络应用都会对你的输入进行散列，并将散列结果与存储的散列进行比较。如果你想了解更多关于安全的密码存储，你可以在我们的平台上进行。

哈希输入需要在计算机上花费一些时间，开发人员总是试图优化他们编写的一切，以使用户有一个流畅的体验。有一件事可以加快程序的速度，那就是在不需要的时候跳过散列。例如，当用户名不存在时（因此不需要检查密码），他们可以立即响应用户。这样他们就可以跳过对密码进行哈希运算的缓慢计算。如果用户名是正确的，他们将对输入的密码进行散列，并将其与存储的散列进行比较。

在这一点上，你可能已经猜到了事情可能出错的地方。尽管在现实中哈希运算只需要几毫秒，但黑客可以利用这个额外的延迟来找出他输入的用户名是否正确，因为一个错误的用户名会有一个稍快的反应，因为没有进行哈希运算。这种类型的旁门左道攻击被称为定时攻击，它是一个很好的例子，说明不同的非功能需求是如何相互抵消的。有时代码不能同时做到快速和安全。

因此，尽管密码处理得很完美，而且显示的信息是通用的，没有提示密码或用户名是否错误，但系统仍有漏洞。解决方法很简单，总是对密码进行哈希处理，或者将发送回复的时间推迟到哈希处理所需的时间。

获得的信息可以被攻击者用来获得系统中的用户列表。这些信息可以用来攻击网络应用程序，例如，通过暴力或默认用户名/密码攻击。

https://www.owasp.org/index.php/Testing_for_User_Enumeration_and_Guessable_User_Account_(OWASP-AT-002)

開発者のセキュリティスキルの重要性は、2022年のガートナー社の「ソフトウェアエンジニアリングにおけるクールベンダー」で強調されています。 レポートの全文はこちらでご覧いただけます。

セキュア・コード・ウォリアーは、4つのうちの1つとして認められていますソフトウェアエンジニアリングにおけるクールなベンダー:開発者の生産性の向上'、ガートナー社ガートナーによると、「クールベンダーの定義とは、革新的でインパクトのある、または興味をそそるテクノロジーやサービスを提供する小規模企業のことです。」クールベンダーには、次の 3 つの要素があります。

革新的 —ユーザーが以前はできなかったことを実行できるようにします。

インパクトのある — テクノロジーそのものだけでなく、ビジネスにも影響を及ぼしている、またはもたらす可能性がある。

興味をそそる —過去6か月間にガートナーの関心を集めました。

レポートで概説されているように、「ソフトウェアエンジニアは、生産性を維持しながら、複雑なコード環境をナビゲートし、構築したシステムのセキュリティを向上させることに苦労しています。これらのクールなベンダーは、ソフトウェアエンジニアリングリーダーが開発者の生産性を高め、セキュリティリスクを軽減するのに役立つ革新的なソリューションを提供しています。」

この評価は、開発者が主導するセキュリティに焦点を当てている唯一の上場企業であり、この評価は、適切なセキュリティスキルとコンテキストツールを備えた開発者がスキルを迅速に学習、構築、適用してソフトウェアのセキュリティを向上させるための安全なコードを迅速に配信できるようにするという当社の戦略の証です。

左にシフトすることのメリットは以前から称賛されてきましたが、多くの組織は、ソフトウェア開発ライフサイクルの最初にセキュリティを考慮に入れることにまだ苦労しています。私たちの最近の '開発者主導のセキュリティ調査の現状 安全なコーディング手法を採用する際に克服すべき最大のハードルは時間不足であることを強調しました。これは最近のガートナー社のレポートにも反映されています。熟練したエンジニアが大幅に不足していることと、膨大で複雑なコードリポジトリと、ランタイムスタックの半分以上がオープンソースソフトウェアで構成されているため、開発者は既存のコードを保守する時間がほとんどありません。セキュリティを確保することは気にしないでください。

Secure Code Warriorのソリューションは、ソフトウェアのセキュリティを確保すると同時に生産性を向上させるというニーズに応えています。前述の調査では、安全なコーディング手法を採用する時間が足りないと回答したにもかかわらず、76% の回答者が、安全なコーディングの適切なトレーニングは実際にはそうなるだろうと回答しました。 生産性の向上 セキュリティチケットの数が減り、管理の手間が省けます。適切なセキュリティスキルとツールがあれば、開発チームはリスクを簡単に軽減し、革新的な機能を備えた、安全で高品質なコードを迅速かつ一貫してリリースできます。

Secure Code Warriorだけでなく、セキュリティスキルのある開発者がサイバーセキュリティにおいて果たすことができる重要な役割を強調してくださったガートナーに感謝します。
‍

にアクセスする ソフトウェアエンジニアリングにおけるガートナー社のクールなベンダー:開発者の生産性の向上 今すぐ報告してください。

‍