Trainer Name: Richárd Kovács , Réka Domján

Title: OWASP Top 10, Secure Coding Fundamentals

Duration: 4 days (4 hrs each day)

Dates: Dec. 19, 2022 To Dec. 22, 2022

Time: 10 a.m. To 2 p.m. IST

Training Objectives

Writing web applications can be rather complex – reasons range from dealing with legacy technologies or under-documented third-party components to sharp deadlines and code maintainability. Yet, beyond all that, what if we told you that attackers were trying to break into your code right now? How likely would they be to succeed?

This course will change the way you look at your code. We'll teach you the common weaknesses and their consequences that can allow hackers to attack your system, and – more importantly – best practices you can apply to protect yourself. We cover typical Web vulnerabilities with a focus on how they affect web apps on the entire stack – from the base environment to modern AJAX and HTML5-based frontends. In addition, we discuss the security aspects of different platforms as well as typical programming mistakes you need to be aware of. We present the entire course through live practical exercises to keep it engaging and fun. Writing secure code will give you a distinct edge over your competitors. It is your choice to be ahead of the pack – take a step and be a game-changer in the fight against cybercrime.

Training level: Basic

Training Outlines

Day 1

IT security and secure coding

  • Nature of security
  • What is the risk?
  • IT security vs. secure coding
  • From vulnerabilities to botnets and cybercrime

Web application security (OWASP Top Ten 2021 summary)

  • Changes in OWASP Top Ten from 2017 to 2021
  • A1 - Broken Access Control
  • Definition and generalization
  • Examples
    • Path traversal
    • Insecure direct object reference (IDOR)
    • Force browsing
    • Typical access control checks
  • Case-study: session management problems
  • Exercise or Demo
  • Best practices and takeaways
  • A2 - Cryptographic Failures
  • Definition and generalization
  • Examples
    • Encoding, encryption, hashing, obfuscation
    • Using weak cryptography
    • Using cryptography incorrectly
  • Case-study: password storage
  • Exercise or Demo
  • Best practices and takeaways

Day 2

A3 - Injection
Definition and generalization

  • Examples
    • HTML, SQL, XML, OS command, etc.
  • Case-study: second-order injection
  • Exercise or Demo
  • Best practices and takeaways
  • A4 - Insecure Design
  • Definition and generalization
  • Examples
    • Principles of Saltzer and Schroeder
    • Client-size authentication
  • Case study: Yahoo celebrity “hack”
  • Exercise or Demo
  • Best practices and takeaways
  • A5 - Security misconfiguration
  • Definition and generalization
  • Examples
    • Default passwords
    • Missing hardening (XML parsers)
    • Open permissions
  • Case-study: XML parsers on the web
  • Exercise or Demo
  • Best practices and takeaways

Day 3

  • A6 - Vulnerable and Outdated Components
  • Definition and generalization
  • Examples
    • Inconsistent patching
    • Using old software
    • Dependency management
  • Case-study: Panama papers
  • Exercise or Demo
  • Best practices and takeaways
  • A7 - Identification and Authentication Failures
  • Definition and generalization
  • Examples
    • Password problems and solutions
    • Session management issues
    • Multi-factor authentication
  • Case-study: credential stuffing
  • Exercise or Demo
  • Best practices and takeaways
  • A8 - Software and Data Integrity Failures
  • Definition and generalization
  • Examples
    • Insecure deserialization
    • Missing integrity checks
    • Confidentiality, Integrity, and Availability
  • Case-study: npm supply chain attack
  • Exercise or Demo
  • Best practices and takeaways

Day 4

  • A9 - Security Logging and Monitoring Failures
  • Definition and generalization
  • Examples
    • Monitoring and logging problems
    • Log forging
  • Case-study: the story of logging
  • Exercise or Demo
  • Best practices and takeaways
  • A10 - Server-Side Request Forgery
  • Definition and generalization
  • Examples
    • Port scanning internal servers
    • Accessing private APIs
  • Case-study: Capital One hack
  • Exercise or Demo
  • Best practices and takeaways
  • Closing

Who Should Attend?

Programmers, software developers, team leaders, managers

What to Bring?

During the training, you will be solving hands-on exercises with the help of the trainer on a cloud virtual machine.

These are the requirements to be able to use the VM smoothly.

Hardware

  • CPU: Intel Core i3 or AMD equivalent
  • RAM: 2 GB
  • Display resolution: 1280x1024
  • 2Mbps Internet connection]
  • Possibly two monitors/displays Software
  • Web browser with HTML5 support to connect to the VM
  • PDF reader to follow along with the PDF handout

Recommended hardware specification

  • CPU: Intel Core i5 or AMD equivalent
  • RAM: 4 GB
  • Display resolution: 1600x900 or higher
  • Secondary display for the course material
  • 10+ Mbps Internet connection

Training Prerequisite

General software engineer capabilities

What attendees will be provided?

Participants will receive a welcome page prior to the training including the course material in a pdf file and access to the cloud VMs during the training.

What to Expect?

  • Understand basic concepts of security, IT security, and secure coding
  • Learn Web vulnerabilities beyond OWASP Top Ten and know how to avoid them
  • Learn about XML security
  • Learn client-side vulnerabilities and secure coding practices
  • Learn about typical coding mistakes and how to avoid them
  • Get information about some recent vulnerabilities in the Java framework
  • Get sources and further readings on secure coding practices

What not to expect?

  • An offensive training with a demonstration of attack tools.
  • Framework specific best-practices (this is a language agnostic course).

About the Trainer

I was studying economics in Vienna when I saw a series about a hacker. He was a grey hat hacker: well-motivated but doing totally illegal things. For IT security, his character inspired me. Then I started reading about this subject, took an online course, studied programming, and as a result, I enrolled in university. It has an IT security lab, and what I saw there impressed me. After the lab demonstration, my path became clear to me. In my undergraduate thesis, I developed an intentionally vulnerable system, attacked it, and then demonstrated the whole process from log files. Clearly, to me outsourcing does not present the best solution – rather, we should aim to have a code base within the team which we make difficult or impossible to access. The industry is changing too fast to predict anything, in three or four years your knowledge can become worthless, but the insight people get from our training can form a permanent part of their future work.

Programming requires a different mindset than most other professions, and IT security work requires a different outlook. At Scademy, I can train people with much more programming experience than I have. However, they don’t know nearly as much about security as I do, as most of them probably didn’t come across it in their training. I started as a curriculum developer at Scademy and then I started teaching, which I like because it gives me very specific knowledge. It also depends on the trainer how dynamically each group works, and their openness. I also feel that some groups work more actively by nature: their members talk to each other, and the process needs moderation. Some people ask a lot of questions, and some learn more passively by nature. But the bottom line remains the same everywhere: what they will do differently in their work from the next day. It is also of big importance whether they will spread the word among their colleagues on how much trouble their carelessness can lead to.