• Skip to main content
  • Skip to primary sidebar
  • Skip to footer

DevelopSec

  • Home
  • Podcast
  • Blog
  • Resources
  • About
  • Schedule a Call

application security

February 10, 2020 by James Jardine Leave a Comment

Chrome is making some changes.. are you ready?

Last year, Chrome announced that it was making a change to default cookies to SameSite:Lax if there is no SameSite setting explicitly set. I wrote about this change last year (https://www.jardinesoftware.net/2019/10/28/samesite-by-default-in-2020/). This change could have an impact on some sites, so it is important that you test this out. The changes are supposed to start rolling out in February (this month). The linked post shows how to force these defaults in both FireFox and Chrome.

In addition to this, Chrome has announced that it is going to start blocking mixed-content downloads (https://blog.chromium.org/2020/02/protecting-users-from-insecure.html). In this case, they are starting in Chrome 83 (June 2020) with blocking executable file downloads (.exe, .apk) that are over HTTP but requested from an HTTPS site.

The issue at hand is that users are mislead into thinking the download is secure due to the requesting page indicating it is over HTTPS. There isn’t a way for them to clearly see that the request is insecure. The linked Chrome blog describes a timeline of how they will slowly block all mixed-content types.

For many sites this might not be a huge concern, but this is a good time to check your sites to determine if you have any type of mixed content and ways to mitigate this.

You can identify mixed content on your site by using the Javascript Console. It can be found under the Developer Tools in your browser. This will prompt a warning when it identifies mixed content. There may also be some scanners you can use that will crawl your site looking for mixed content.

To help mitigate this from a high level, you could implement CSP to upgrade insecure requests:

Content-Security-Policy: upgrade-insecure-requests

This can help by upgrading insecure requests, but it is not supported in all browsers. The following post goes into a lot of detail on mixed content and some ways to resolve it: https://developers.google.com/web/fundamentals/security/prevent-mixed-content/fixing-mixed-content

The increase in protections of the browsers can help reduce the overall threats, but always remember that it is the developer’s responsibility to implement the proper design and protections. Not all browsers are the same and you can’t rely on the browser to provide all the protections.

Filed Under: General Tagged With: application security, AppSec, chrome, developer, secure code, secure development, secure testing

February 10, 2020 by James Jardine Leave a Comment

Ep. 117: How Browsers are Helping with Security

Browsers play a role in web application security, but where does their responsibility stop and the developer’s start? In this episode, we are going to discuss a few changes happening in the Chrome browser, that change security by default.

Listen to the Episode:

SameSite Default
Chrome has announced a few changes that we need to watch out for in the near future. We previously talked about the default value for samesite that is coming up fast. I wrote about this here: https://www.jardinesoftware.net/2019/10/28/samesite-by-default-in-2020/

This change could impact any application and as developers we should be aware of security defaults in the browsers.

Mixed Content
Also, they are getting ready to start blocking mixed content downloads:
https://blog.chromium.org/2020/02/protecting-users-from-insecure.html

For more info go to https://www.developsec.com or follow us on twitter (@developsec).

[Read more…] about Ep. 117: How Browsers are Helping with Security

Filed Under: Podcast Tagged With: application security, AppSec, awareness, chrome, cross site request forgery, developer training, mixed content, same site, samesite, secure development, secure training, security training, training

November 15, 2019 by James Jardine Leave a Comment

Ep. 116: Chrome Retires XSS Auditor

Do you rely on the browser to protect your application from Cross-Site Scripting? Over the years, many of the popular browsers attempted to create these XSS filters to help reduce the risk of the vulnerability. Unfortunately, over the years we have seen a lot of bypasses to these filters. Chrome announced they are removing their XSS Auditor. Hear some of our thoughts on the changes.

Listen to the Episode:

 

References

https://www.chromium.org/developers/design-documents/xss-auditor

[Read more…] about Ep. 116: Chrome Retires XSS Auditor

Filed Under: Podcast Tagged With: application security, AppSec, cross site scripting, developer training, sdlc, secure code, secure development, secure sdlc, security awareness, training, xss

November 7, 2019 by James Jardine Leave a Comment

Ep. 115: Is CSRF Really Dead?

In 2020, Chrome will default the SameSite attribute to Lax on all cookies. SameSite helps mitigate CSRF, but does that mean CSRF is Dead?

For more info go to https://www.developsec.com or follow us on twitter (@developsec).

Join the conversations.. join our slack channel. Email james@developsec.com for an invitation.

 DevelopSec provides application security training to add value to your application security program. Contact us today to see how we can help.

[Read more…] about Ep. 115: Is CSRF Really Dead?

Filed Under: Podcast Tagged With: app sec, application security, AppSec, cross site request forgery, CSRF, pen testing, secure development, security education, security testing

October 8, 2019 by James Jardine

Investing in People for Better Application Security

Application security, like any facet of security, is a complex challenge with a mountain of solutions. Of course, no one solution is complete. Even throwing multiple solutions will never get 100% coverage.

The push today is around devsecops, or pushing left in the SDLC. I am seeing more solutions recommending also pushing right in the SDLC. I feel like we are stuck at this crossroad where the arrow points both ways.

The good news is that none of these recommendations are wrong. We do need to push left in the SDLC. The sooner we address issues, the better off we are. The idea that if we don’t introduce a vulnerability in the first place is the best case scenario. Unfortunately, we also know that is an unrealistic assumption. So this brings us to pushing right. Here, we are looking to quickly identify issues after they are introduced and, in some cases, actively block attacks. Of course, let’s not leave out that automation is our key to scalable solutions as we build and deploy our applications.

Much of what we focus on is bringing in some form of tool. Tools are great. They take they mundane, repetitive work off of our plate. Unfortunately, they can’t do it all. In fact, many tools need someone that has at least some knowledge of the subject. This is where the people come in.

Over the years, I have worked with many companies as both a developer and an application security expert. I have seen many organizations that put a lot of effort into building an application security team, focused on managing everything application security. Often times, this team is separate from the application development teams. This can create a lot of friction. With the main focus on the application security team, many organizations don’t put as much effort into the actual application development teams.

How does your organization prepare developers, business analysts, project managers and software testers to create secure applications?

In my experience, the following are some common responses. Please feel free to share with me your answers.

  • The organization provides computer based training (CBT) modules for the development teams to watch.
  • The organization sends a few developers to a conference or specialized training course and expects them to brief everyone when they return.
  • The organization brings in an instructor to give an in-house 2-3 day trading class on secure development (once a year).
  • The organization uses its security personnel to provide secure development training to the developers.
  • The organization provides SAST or DAST tools, but the results are reviewed by the security team.
  • The organization has updated the SDLC to included security checkpoints, but no training is provided to the development teams.
  • The organization doesn’t provide any training on security for the development teams.

By no means is this an exhaustive list, but just some of the more common scenarios I have seen. To be fair, many of these responses have a varying range of success across organizations. We will look at some of the pitfalls too many of these approaches in future articles.

The most important point I want to make is that the development teams are the closest you can get to the actual building of the application. The business analysts are helping flush out requirements and design. The developers are writing the actual code, dealing with different languages and frameworks. The QA team, or software testers, are on the front line of testing the application to ensure that it works as expected. These groups know the application inside and out. To help them understand the types of risk they face and techniques to avoid them is crucial to any secure application development program.

My goal is not, let me repeat, NOT, to turn your application development teams into “security” people. I see this concept floating around on social media and I am not a fan. Why? First and foremost, each of you have your own identity, your own role. If you are a developer, you are a developer, not a security person. If you are a software tester, don’t try to be a security person. In these roles, you have a primary role and security is a part of that. It is not the defining attribute of your tasks.

Instead, the goal is to make you aware of how security fits into your role. As a software tester, the historical goals focused on ensuring that the application functions as expected. Looking at validating use cases. When we start to think about security within our role, we start to look at abuse cases. There becomes a desire to ensure that the application doesn’t act in certain ways. Sometimes this is very easy and others it may be beyond our capabilities.

Take the software tester again. The goal is not to turn you into a penetration tester. That role requires much more in-depth knowledge, and honestly, should be reserved for looking for the most complex vulnerabilities. This doesn’t mean that you can’t do simple tests for Direct Object Reference by changing a simple ID in the URL. It doesn’t mean that you don’t understand how to do some simple checks for SQL Injection or Cross-site Scripting. It does mean you should be able to understand what the common vulnerabilities are and how to do some simple tests for them.

If you invest in your people correctly, you will start to realize how quickly application security becomes more manageable. It becomes more scalable. The challenge becomes how to efficiently train your people to provide the right information at the right time. What type of support are you looking for? Is it the simple CBT program, or do you desire something more fluid and ongoing that provides continuing support for your most valuable assets?

Different programs work for different organizations. In all cases, it is important to work with your teams to identify what solution works best for them. Providing the right type of training, mentorship, or support at the right time can make a huge impact.

Don’t just buy a training solution, look for a partner in your development teams training efforts. A partner that gets to know your situation, that is available at the right times, and builds an on-going relationship with the team.

Filed Under: General Tagged With: application security, application security program, developer awareness, developer training, secure code, secure development, security training, training

October 8, 2019 by James Jardine Leave a Comment

What is the difference between source code review and static analysis?

Static analysis is the process of using automation to analyze the application’s code base for known security patterns. It uses different methods, such as following data from it source (input) to its sink (output) to identify potential weaknesses. It also uses simple search methods in an attempt to identify hard-coded values, like passwords in the code. Automated tools struggle at finding business logic or authentication/authorization flaws.

Code Review is a much larger project where both automated and manual techniques are used to review a code base for potential security risks. A code review may incorporate a static analysis component to quickly scan for some types of vulnerabilities. The manual part of the secure code review involves a person looking at the code to identify flaws that automated scanners cannot. For example, they may look at the authentication logic looking for potential logic flaws. They may also look to identify other authorization or business logic flaws that the automation is challenged to find.

Filed Under: Questions Tagged With: application security, code review, development, sast, secure code review, secure coding, secure development, secure sdlc, security, testing

  • « Go to Previous Page
  • Go to page 1
  • Go to page 2
  • Go to page 3
  • Go to page 4
  • Interim pages omitted …
  • Go to page 10
  • Go to Next Page »

Primary Sidebar

Contact Us:

Contact us today to see how we can help.
Contact Us

Footer

Company Profile

Are you tackling the challenge to integrate security into the development process? Application security can be a complex task and often … Read More... about Home

Resources

Podcasts
DevelopSec
Down the Security Rabbithole (#DTSR)

Blogs
DevelopSec
Jardine Software

Engage With Us

  • Email
  • GitHub
  • Twitter
  • YouTube

Contact Us

DevelopSec
Email: james@developsec.com



Privacy Policy

© Copyright 2018 Developsec · All Rights Reserved