If a developer writes a cross-site scripting error as they're coding in JavaScript, and they're able to detect that within minutes of creating that flaw, it will likely only require minutes or seconds to fix.

Whereas if that flaw is discovered two weeks later by a manual tester, that's going to be then entered into a defect tracking system. It's going to be triaged. It's going to be put into someone's bug queue.

With the delay in identification, it will have to be researched in its original context and will slow down development. Now, you're potentially talking hours of time to fix the same flaw. Maybe a scale of 10 or 100 times more time is taken

I couldn't agree with Chris Wysopal (CTO, Veracode) more in his recent podcast with O'Reilly Security Podcast where he explains why shifting security to the left (to developers at the start of the development life cycle) is key in an agile environment to keep up the pace and speed.

Security should be made easy for developers by using IDE plug-ins, scanners and educating them to have the basic security skills (hygiene). Organisations should not be solely relying on security experts or a centralised security team who validates all changes.

Our typical security modus operandi is broken (call in the expert!) and we need to integrate security into development teams to ensure quality is maintained whilst staying agile.

https://www.oreilly.com/ideas/chris-wysopal-on-a-shared-responsibility-model-for-developers-and-defenders

I am glad to see Secure Code Warrior is not the only one thinking about how to deliver a change in behavior within a company using positive reinforcement and game-based elements.

This article in the WSJ really highlighted that cybersecurity awareness is more effective and has a greater impact on employees when the training is not dreadful, boring, repetitive or just useless. In the past, cybersecurity training was typically delivered by security experts who were technical and provided in-depth material but without much thought on how to deliver key messages that stuck with employees.

However, more and more, certainly with clients we work with, I am seeing how organizations are now involving marketing and communication teams and change managers, as well as using digital animation in their content and running events and challenges to make cybersecurity training more fun and engaging. With cybsersecurity threats growing year after year, security awareness and employee training is the most important investment your organization can make.

Positive-reinforcement campaigns are often one of the best ways to modify risky behavior, but they're "definitely an outlier" in the corporate world, says Ms. Sedova

https://www.wsj.com/articles/a-better-way-to-teach-cybersecurity-to-workers-1505700120

There's a question that needs to be asked by every developer, whether you are a graduate or a veteran. And the answer matters. It's become even more important in an agile world as it will directly impact how successful you will be at software engineering; and how valuable you will be to you next employer.

It's the million dollar question. Actually, it's the multi-multi million dollar question!

Are you committed to helping me to code securely?

The average cost of a data breach now stands at USD$3.6M. The odds of your company being breached this year are as high as one in four. Given these facts, I share the frustrations of many that developers aren't graduating from university with competency in secure coding and security embedded into their DNA.  

Why? Software engineering is still a relatively young profession. The emphasis has been on teaching people how to build code quickly, make it elegant and functional, but with very limited focus on making the code secure. The pace of change in methodologies, technologies, languages and opportunities only exacerbates these key skill gaps.

We aren't going to change the academic system quickly, so developers and companies alike should expect that developers need to learn secure coding skills on the job. In some professions, you can learn by making mistakes, but for others, it isn't an option. So it is with cyber security.

The facts show that we haven't done very well with on-the-job developer security training either. Most of the world's major security breaches are due to coding errors which allow hackers gain privileges on computer networks, enabling them to access and harvest valuable data. The Verizon Data Breach Investigation Report (DBIR) 2017, shows that 30% of all breaches are directly caused by weaknesses in web applications security and this conclusion has been consistent in the DBIR report since 2013.

The 2017 Global DevSecOps Skills Survey released in August 2017, confirmed what we already knew: while 65 percent of DevOps professionals believe it is very important to have knowledge of DevSecOps when entering IT, 70 percent feel they're not receiving the necessary training through formal education to be successful in today's DevSecOps world.

Nearly 40 percent of hiring managers surveyed reported that the hardest employees to find are the all-purpose high-end developers with sufficient knowledge about security testing. 70 percent of respondents said the security education they had received is not adequate for their current positions. In fact, less than 4% said they are afforded the opportunity at all.

I saw this first hand when I spent almost a decade working with multiple teams of professional white-hat hackers. With tragic regularity, we broke into large enterprises, start-ups and government departments; always finding the same weaknesses.

This is why developers need to speak up when you are being hired. If your prospective employer isn't taking your developer security training seriously, you should think about what sort of company you are considering joining.

The second question you should ask is how they plan to deliver it. Will it be hands-on and interactive? Developer security training on vulnerabilities using slideware, videos, clickable animations, or abstract discussions are unlikely to assist you directly in your coding. Will they ensure you are continually kept up to date with the latest vulnerabilities? Is there a security guild or community where you can learn from? Are there security mavens who can you can fall back to if you need help?

A commitment to your secure coding skills needs continuous learning through hands-on challenges in specific coding frameworks and confronting you with different vulnerabilities in multiple scenarios. You simply cannot learn about SQL injections through one example. You need exposure to multiple examples of diverse types so that you learn to recognise these dangerous coding patterns.

One of our customers required their developers play a single challenge (5 minutes) every day for two months. It tested their skills before and after the training period and observed a 60% increase in secure coding capability over a group of hundreds of developers. This means less resources spent on finding and fixing security bugs later in the life-cycle and significant long-term savings. It means hackers won't use your code to compromise your company's data.

There were 11 million professional developers in the world in 2014, according to IDC research. In 2015, Burning Glass found there were as many as 7 million job occupations that required coding skills and that programming jobs were growing on average 12% faster than the market.

There are plenty of software jobs out there. So take a stand and choose employers who are committed to taking care of their security, your security and their customers' security.  By extension, chose companies who invest in you.

There's a question that needs to be asked by every developer, whether you are a graduate or a veteran. And the answer matters. It's become even more important in an agile world as it will directly impact how successful you will be at software engineering; and how valuable you will be to you next employer.

It's the million dollar question. Actually, it's the multi-multi million dollar question!

Are you committed to helping me to code securely?

Last week I was researching vulnerabilities in Java Spring to bring our secure coding guidelines up to date. I was going through the existing challenges on our platform and noticed a few on XSS through displaying url parameters in JSP pages. The incorrect code example would look something similar to the following:

   <input type="text" name="username" value="${param.username}">

The correct solution was removing the URL parameter altogether and the description mentions that escaping the URL parameter the correct way is also safe.

Now, my job is to formulate the secure coding guideline in a way that is clear to developers and restricts them as little as possible while still writing secure code. In this case, I would prefer to let developers keep their intended functionality and recommend them to do it securely by escaping the URL parameter. This way, the code no longer contains a XSS vulnerability. The above example can be secured like this:

   <input type="text" name="username" value="${fn:escapeXml(param.username)}">

And this was our secure coding guideline for a few days, until I stumbled on an OWASP page on expression language injection. This page describes how the Spring Expression Language (SpEL) can be abused for injection with some serious impact, including remote code execution. It was up to me to figure out if there could be cases where code adhering to our secure coding guideline can still be affected by this vulnerability. So I wrote a quick test application to evaluate SpEL expressions, and tested input with and without Xml escaping to see if I could find some scenarios that would not be caught. And I did, there are malicious expressions that do not contain any characters caught by XmlEscape. I published the working demo on our github, which you can find here.

And of course I updated our secure coding guideline which now reads: "Do not display or evaluate URL parameters using the Spring Expression Language (SpEL)."

The overall impact of this issue is High, for the following reasons:  - An attacker could modify and invoke functionality on the application server. - Unauthorized access to data and functionality, as well as account hijacking and remote code execution. - Confidentiality, and Integrity concerns from a successful attack.

https://www.owasp.org/index.php/Expression_Language_Injection

Security issues identified in 2016 on the Equifax website are still not fixed. It is one step to identify the problem but it's an even bigger challenge to fix it. It requires time and skill to go back into the code, understand the context and fix the issues.

It is clear developers at Equifax were under a lot of stress and many known vulnerabilities didn't get fixed. Unfortunately that lack of action has now had the worst possible response.

Security needs to be baked in from the start and developers needs the skills, training and in-IDE tools to minimize writing known vulnerabilities. It requires specific language and framework knowledge to fix the problems identified. The general principle on fixing a XSS issue stays the same, however the actual implementation is dependent on the frameworks in place.

If you want to do some interactive training on how to fix XSS issues in Struts, check out: https://portal.securecodewarrior.com/#/simple-flow/web/xss/reflected/java/struts

Skip forward to 2016 and a security researcher found a common vulnerability known as cross-site scripting (XSS) on the main Equifax website, according to a tweet from a researcher who goes by the name x0rz. Such XSS bugs allow attackers to send specially-crafted links to Equifax customers and, if the target clicks through and is logged into the site, their username and password can be revealed to the hacker.

https://www.forbes.com/sites/thomasbrewster/2017/09/08/equifax-data-breach-history/#552ab1c9677c

Last week, it was reported that a possible cause behind the Equifax data breach was a vulnerability in the Apache Struts REST plugin. The older version of the plugin is vulnerable to Remote Code Execution attacks when it is used with XStream handler to handle XML payloads. The cause is deserialization of untrusted data, which is a well-known vulnerability type. The vulnerability, officially recognized as CVE-2017-9805, was patched by Apache September 5th in the Struts version 2.5.13. It was then announced and clearly documented in the Apache Struts documentation.

Simply upgrading to the newest Struts version can protect the application from this attack, so why do companies not upgrade immediately? The problem with deserialization vulnerabilities is that the routines that are being exploited are often those that the application code relies on. In this case, applying the new Struts patch might have some side effects, as the documentation on the vulnerability mentions, "It is possible that some REST actions stop working because of applied default restrictions on available classes." It is very likely that making sure the application keeps working on newer versions of Struts takes some time.

Hackers, however, do not need as much time to start abusing published vulnerabilities, and we can already see some exploits published. A Metasploit module was added September 8th, that's three days after Apache patched the vulnerability. Postponing your patch is clearly not a good idea!

The solution is to implement a workaround suggested by Apache, which could be done in a shorter time frame. A security tool with configurable coding guidelines to enforce this workaround or even automatically apply it would greatly speed up this process.

Do you want to know more about how to identify and secure code that contains deserialization of untrusted data? Visit the Secure Code Warrior portal for a clear explanation and a training challenge.

The vulnerability relates to how Struts parses that kind of data and converts it into information that can be interpreted by the Java programming language. When the vulnerability is successfully exploited, malicious code can be hidden inside of such data, and executed when Struts attempts to convert it.

https://qz.com/1073221/the-hackers-who-broke-into-equifax-exploited-a-nine-year-old-security-flaw/

One of the difficulties with learning a new library, or sharing agreed practices across our team is documenting and creating examples.

Very often we create small example projects, but we don't have them open when working with actual code.

I've often thought it would be great to have the ability to link to our examples, or online examples and be able to go to a URL for more explanation when needed.

With Java, we have JavaDoc comments, which can have a see annotation:

/**
 * @see <a href="https://junit.org/junit5/docs/current/user-guide/#writing-tests-annotations">Junit 5 Annotation docs</a>
 */

JavaDoc like this in 3rd party libraries is a great help because we can use the Quick Documentation functionality in IntelliJ to have access to more detailed examples.

But, we all know that comments don't get updated as often as code, and web presence maintenance is often disconnected from library maintenance and sometimes performed by a different team entirely.

How Sensei Helps

Sensei provides the ability to match on library annotations and methods to provide links to long form documentation on a wiki or third party tutorial site.

As an example, I'm using the @Test annotation from JUnit.

The JavaDoc is very detailed, and the Quick Documentation view explains how to use the annotation.

But the official documentation on the web site is often easier to read and has more examples.

When a team starts learning a library, having a set of recommended tutorials, can be very useful.

Sensei has a goto action that we can use to open a URL, allowing us to link to external sites and examples for documentation that we, as a team, find useful.

Implementing the Goto URL

To implement this I would create a search that matches the @Test annotation from Junit.

search:
   annotation:
    owner:
      method: {}
    type: "org.junit.jupiter.api.Test"

And then I would add goto actions for each of the URLs I find useful.

e.g.

• https://junit.org/junit5/docs/current/user-guide/#writing-tests-annotations
• https://junit.org/junit5/docs/current/user-guide/#writing-tests-classes-and-methods

The example below would create a single Action JUnit Annotations (learn) which would open both URLs in a browser at the same time.

availableFixes:
- name: "Learn about JUnit Annotations"
  actions:
  - goto:
      type: "URL"
      value: "https://junit.org/junit5/docs/current/user-guide/#writing-tests-annotations"=
  - goto:
      type: "URL"
      value: "https://junit.org/junit5/docs/current/user-guide/#writing-tests-classes-and-methods"

And when I activate it in IntelliJ with Alt+Enter I see the context menu which I can select to jump to the documentation.

Multiple Actions

I might choose to have multiple Actions so that each URL or tutorial has its own option in the alt+enter Quick Fix pop up menu.

For example, for the @Parameterized annotation, I might want to link to the official documentation and a set of online example code.

• https://junit.org/junit5/docs/current/user-guide/#writing-tests-parameterized-tests
• https://github.com/eviltester/junitexamples/blob/master/src/test/java/parameterized/junit5/InitialExampleTest.java

I would simply create a recipe that searches for the annotation:

search:
  annotation:
    owner:
      method: {}
    type: "org.junit.jupiter.params.ParameterizedTest"

And links off to the sites I identified as being useful:

availableFixes:
- name: "JUnit Annotations (learn)"
  actions:
  - goto:
      type: "URL"
      value: "https://junit.org/junit5/docs/current/user-guide/#writing-tests-annotations"
- name: "What is a JUnit Test? (learn)"
  actions:
  - goto:
      type: "URL"
      value: "https://junit.org/junit5/docs/current/user-guide/#writing-tests-classes-and-methods"

Both links would then appear in the pop-up dialog.

Who would benefit?

I would have found this useful when using and learning libraries, especially when leading teams and helping them adopt a new library.

This could also benefit teams creating libraries, by creating a standard set of documentation recipes to help guide people through the adoption of the library or new features in the library.

This would be especially useful if the code maintenance and documentation maintenance are performed by different teams.

You can install Sensei from within IntelliJ using `preferences > plugins` (just search for "sensei secure code").

All the code for this blog post is on Github in the junitexamples module in https://github.com/SecureCodeWarrior/sensei-blog-examples

Once again, the root cause of the Equifax hack is a web app vulnerability. These type of vulnerabilities have been around for over a decade but are still so relevant today. Each developer should be given the tools to avoid introducing these problems in the first place through training and real-time guidance while developing code.

Equifax said it discovered the breach on July 29. "Criminals exploited a U.S. website application vulnerability to gain access to certain files," the company said.

Read more: Credit-reporting-firm-equifax-says-cybersecurity-incident-could-potentially-affect-143-million-us-consumers

Hi everyone!

With September wrapped up, we wanted to take the opportunity to go over the most exciting updates we delivered for Sensei during September. You can also jump straight into trying Sensei for yourself by installing it directly from the JetBrains Marketplace. 

Tags

We wanted to support the ability to add custom metadata, which you can use to categorize and group recipes. We۪'ve now added the ability to add tags onto recipes. 
‍

We've heard from customers that they want to see metrics about how recipes are used, without necessarily revealing too much about the recipes in the metrics. Tags are one step towards that goal, giving teams relevant metrics to drive their quality programs. 

‍

Variable browser

When you are creating a recipe, it's very useful to understand how the elements of the code you're matching are structured, and thus help search against it. To this end, we've added our variable browser into the recipe editor in more places. The variables shown are relative to the selected target. This helps you understand your code and craft a good recipe with less effort.
‍

Cookbook manager update

We've moved the cookbook manager into a panel within the IDE, rather than rely on popping up a new window. This makes the experience of managing cookbooks a much simpler and smoother experience. Instead of having to open up the window, you can simply expand it directly from your sidebar!

Try out Sensei now! 

Sensei is available, for free, on the JetBrains Marketplace. We are actively developing and improving it and look forward to learning how you incorporate it into your development process.