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.

In this blog post, we will:

• Demonstrate searching and matching annotations
• Amen annotations using mustache templates

Sensei provides the ability to match problematic code patterns and then amend them to agreed implementations. In this example, I am using @Disabled without a parameter as the problematic code pattern.

Disabled Test Annotation

Disabled tests without a specified reason can prove problematic over the long term because we forget why we disabled it.

@Disabled
   void thisTestMethodHasNoDisabledReason(){
    Assertions.fail("This test is disabled and should not run");
    }

The risk is that, over time, the code base moves on, the disabled test is not updated in step with the purpose of the code and eventually becomes redundant and irrelevant, and potentially never re-enabled.

During code reviews, we will often point out that it is a good idea to add an explanatory description as the annotation parameter.

@Disabled ("Disabled to demonstrate adding a reason")
    void thisTestMethodHasDisabledReason(){
   Assertions.fail("This test is disabled and should not run");
   }

A Sensei Recipe

We can write a recipe to detect when @Disabled is added without explanation and a Quick Fix that reminds us to add the actual reason explaining why we disabled it.

When I think about what I'm going to do, I have to:

• match the Disabled annotation without any parameters
• change the Disabled annotation to have a parameter with marker text "TODO: add a description here"

Create a Warning Recipe

I use Alt+Enter to Create a new Recipe.

Then add the basic descriptive text in the general information.

By making the rule a warning, any matching code is highlighted but not shown as a glaring error.

Find the Annotation

In the recipe editor, I change the Search to match an annotation.

This will highlight all annotations in the preview.

Having done that, I want to filter on the type of annotation.

I could just use Disabled but I fully qualify the class with the package so that it only matches the annotation from JUnit 5. Because the source code is shown in the preview, I can easily copy and paste this in from the actual code to avoid any typos.

I then want to match only annotations without Parameters, and I can use the GUI to do that.

i.e. Search:

search:
  annotation:
    type: "org.junit.jupiter.api.Disabled"
    without:
       parameters:
          - {}

Create a Rewrite Quick Fix Action

For my QuickFix I will use a rewrite action.

I use the Show Variables functionality to show me the Mustache variables and preview the contents.

And then I add the extra code needed to create the place marker comment.

i.e. QuickFix:

availableFixes:
 - name: "Add a todo comment parameter"
   actions:
   - rewrite:
      to: "{{{ . }}}(\"TODO: add a description here\")"
      target: "self"

Sensei in Action

We have created a short video showing the recipe creation process in action.

Summary

When building a rewrite Quick Fix, it is easier when we can search for the code element that we want to rewrite, because it is then the self entity we can act on.

In this example, I used a rewrite action to amend the Annotation. Rewrite is a general-purpose action that can apply to any code element and is a good default to explore.

The Sensei plugin provides an easy way to find specific code patterns in your source code, and then apply rewrite rules to amend the matching code. All within the Intellij IDE, and in real-time.

‍

‍

For example, you could create a rule that matches on JUnit `@Disabled` annotations which do not have a reason, Sensei would then tell you about the issue by highlighting the code in the IDE.

Additionally, when you `alt+enter`, you can have the option to `Add a todo comment parameter`.

When selected, this would amend the code to add a boilerplate reason, which you can then amend, and if you don't, it will show up in your TODO panel.

e.g. `@Disabled` would become ` @Disabled("TODO: add a description here")`

Sensei combines the functionality of a Static Analysis code scanner with a code rewriting engine.

IntelliJ Intention Actions

Based on the above description, the obvious alternative (if you were not using Sensei) is to use the IntelliJ Intention Actions functionality.

Sensei differs from IntelliJ Intention Actions because the aim with Sensei is to provide a way to create matchers and rewriters which are project specific, or even local to an individual developer.

We have tried to put together a GUI that makes both the matching and rewrite rules easy to write and experiment with.

How can it help me personally improve?

When I'm learning a new library, it takes me time to build up muscle memory around the methods and formatting. So I might choose to create personal recipes which

• link off to the official documentation or tutorial pages
• have boilerplate templates which are most effective
• fix poor coding practices
• add boilerplate code to help use a library

I can use Sensei to build temporary recipes which prompt me for the current practices I've chosen to use and help me build up effective habits. And the recipes are temporary because I can remove them when I outgrow them.

How can it help my team improve?

In the same way we can help teams build up muscle memory around agreed coding standards.

Creating cookbooks of recipes that we apply when we find the same comments in pull request reviews. Since the cookbooks are stored in version control with the project, they are available to everyone on the project. And we can switch them off when we no longer need prompting.

Sensei helps provide feedback early

What we've tried to build with Sensei is a way of pulling the feedback that helps us improve, and reminders of corrective action, as early into the coding process as we can.

Rather than wait for

• the results of a static analyser
• the comments from a code review

We can instead see the feedback, for custom standards we want to enforce, as we code.

And we have either reminders, or actual rewrite rules, to help us write code that complies with the standards.

Sensei is flexible

In that way, Sensei is a bit of a mix, since it's:

• part Static Analyser
• coding tutor
• rewrite engine

Sensei is flexible enough to make the job of saying "What is Sensei?" that little bit harder.

Sensei fills a gap in the programming workflow

We've tried to make Sensei the missing piece of the programmer workflow that helps you improve specific elements in your coding style, or library use, that you and your team are currently working with.

This flexibility means that it takes a little more time to get to grips with Sensei than a static analysis tool or the built-in IntelliJ Intentions. Still, by spending the time to experiment, you will gain a new way to speed up your learning in your personal development process.

How to experiment?

Once you have downloaded and installed Sensei from the [Intellij Marketplace]

The easiest way to make Sensei work for you is to look at your coding process and consider:

• What documentation do you keep looking up?
  -- You could add some Sensei recipes that link back to that documentation.
• What simple mistakes do you keep making?
  -- You could temporarily codify that poor coding pattern as a matcher, and write a Quick Fix rewrite that amends the code to be what you really want to write.
• What boilerplate code do you write to use a library?
  -- You could create a Quick Fix rule to write the code for you.

Since Sensei is designed to work alongside whatever static analysis tool you're using, if you find that the same violations are being reported from static analysis, then you could replicate the condition in a Sensei recipe. You can then add a Quick Fix to help train you, not just to identify the mistake, but also to move quickly to writing the correct code