Forem: SmartScanner

Does Your App Reveal Its Server Header? You Might Be Helping Attackers

SmartScanner — Mon, 23 Feb 2026 13:00:38 +0000

Most developers focus on fixing SQL injection, XSS, and authentication bugs.

But many applications expose something far simpler and surprisingly useful to attackers:

Server: Apache/2.4.50 (Debian)

This single line can dramatically reduce the effort required to compromise your system.

Let’s break down why this matters, how attackers use it, and how you can fix it in minutes.

What Is the Server Header?

Every HTTP response may include a Server header that identifies the web server software handling the request.

Example:

curl -I https://example.com

Response:

HTTP/1.1 200 OK
Date: Mon, 17 Mar 2025 10:25:28 GMT
Server: Apache/2.4.50 (Debian)
Content-Type: text/html

This reveals:

Server software: Apache
Version: 2.4.50
OS: Debian

From a functionality perspective, this header is unnecessary. Your application works perfectly fine without exposing this information.

From a security perspective, it’s valuable intelligence.

Why This Is Dangerous

The header itself is not a vulnerability. But it makes exploitation faster, easier, and more reliable.

Think of it like leaving a note on your front door:

"This house uses Lock Model X, version 1.2 — known to be pickable."

An attacker no longer needs to guess.
They know exactly what to target.

How Attackers Actually Use It

Here’s a typical attack workflow:

Step 1: Scan target

Attacker sends a simple request:

curl -I https://target.com

Sees:

Server: Apache/2.4.50

Step 2: Search for known vulnerabilities

They search vulnerability databases and find:

CVE-2021-41773 — Path traversal and remote code execution in Apache 2.4.50.

Public exploits exist.

Step 3: Run the exploit

No guesswork. No brute force. Just targeted exploitation. What could have taken hours now takes minutes.

Why This Matters More Than You Think

Attackers rarely hack manually anymore. They automate reconnaissance at scale.
Bots scan millions of servers and classify targets based on headers.

Example automation logic:

IF Server == Apache/2.4.50
THEN run exploit CVE-2021-41773

Your server becomes part of an automated attack pipeline.

How to Check Your Own Application

You can test your app in seconds.

Option 1: curl

curl -I https://yourdomain.com

Option 2: Browser DevTools

Open DevTools → Network tab
Reload page
Click request → Headers
Look for Server

How to Automatically Detect This Across Your Apps

Manually checking one app is easy. Checking dozens is not.

Security scanners can automatically detect server version disclosure and other risks.

For example, you can scan your application using SmartScanner:

👉 TheSmartScanner.com

It detects:

Server version disclosure
Security misconfigurations
OWASP Top 10 vulnerabilities
Information leakage issues

It’s especially useful if you manage multiple apps or environments.

How to Fix It (Quick Wins)

Goal: Remove or obfuscate the Server header.

Nginx

server_tokens off;

Apache

ServerTokens Prod
ServerSignature Off

ASP.NET (web.config)

<system.webServer>
  <security>
    <requestFiltering removeServerHeader="true" />
  </security>
</system.webServer>

Node.js (Express)

app.disable('x-powered-by');

You may also need a reverse proxy (Nginx, Cloudflare, etc.) to fully remove headers.

Important: This Is NOT a Substitute for Updating

Removing the header does not fix vulnerabilities. It only removes reconnaissance data.

Think of it as:

Locking your doors (good)
Still patch your system (essential)

Always:

Keep servers updated
Apply security patches
Use supported versions

Bonus: Other Headers You Should Review

These can also leak information:

X-Powered-By: ASP.NET
X-AspNet-Version: 4.0.30319
X-AspNetMvc-Version: 5.2

Remove them unless absolutely required.

Quick Security Checklist

Do this today:

[ ] Remove Server header
[ ] Remove X-Powered-By header
[ ] Update server software
[ ] Use supported versions only
[ ] Put a reverse proxy in front of your app

Final Thoughts

Most breaches don’t start with sophisticated zero-day exploits. They start with information disclosure. Something as small as a response header can be the first domino.

Fix it now. It takes minutes. But it removes valuable intelligence from attackers.

Introducing SmartScanner: Your Go-To Security Buddy for Node.js

SmartScanner — Wed, 26 Feb 2025 07:21:09 +0000

Hey Node.js developers! We all know that building awesome apps with Node.js—from APIs to full-stack solutions—is a blast. But with great power comes great responsibility: security. Whether you're working on an Express API, a NestJS backend, or a NextJS project, keeping your application safe is a must. That's where SmartScanner comes in.

SmartScanner is a super-easy security scanning tool designed to help you find and fix vulnerabilities in your Node.js apps. It’s like having an extra pair of eyes checking your code while you focus on building cool features.

Why Node.js Security Matters

Node.js is everywhere, handling everything from sensitive user data to complex business logic. But with its massive ecosystem and third-party packages, security issues can sneak in. Some common threats include:

Injection Attacks: SQL, NoSQL, or command injections can lead to big problems.
Cross-Site Scripting (XSS): Malicious scripts can damage user trust.
Misconfigurations: Even a small misstep can expose sensitive info.
Vulnerable Dependencies: Some npm packages might have known security issues.

Staying on top of these risks is key to keeping your users safe and your reputation solid.

Meet SmartScanner: Your Security Sidekick

SmartScanner automates the security check of your Node.js app so you can focus on coding. Here’s why it’s a must-have:

Easy to Use: Just enter your app’s URL, hit “Scan,” and let SmartScanner do its magic.
Detailed Reports: Get clear insights on what’s wrong and how to fix it.
Framework-Friendly: Works great with Express, NestJS, and NextJS.
Real-World Testing: Simulate different HTTP methods and authentication to see how your app holds up.
Automation: Use SmartScanner's command line interface to automate your testing process.

SmartScanner is all about helping you build secure applications without the headache.

How to Get Started with SmartScanner

Install SmartScanner:

Download and Install SmartScanner.
Deploy Your App:

Fire up your Node.js server. Whether it’s an API, a NestJS module, or a NextJS project, make sure it’s accessible (for example, http://localhost:3000).
Run SmartScanner:

Open SmartScanner, paste your app’s URL, and click “Scan.”

Tip: Use SmartScanner’s HTTP testing tab to simulate POST, PUT, or DELETE requests with custom headers and payloads.
Review the Report:

Check out the detailed results. SmartScanner will list vulnerabilities—including issues like XSS—that need fixing. Make your changes, then scan again to confirm everything’s locked down.

Real-World Examples: How SmartScanner Enhances Your Code

1. Locking Down Your Express API

APIs are the backbone of many apps, but they can be vulnerable if not secured properly. Here’s a friendly example with Express:

const express = require('express');
const helmet = require('helmet');

const app = express();

// Add Helmet to set secure HTTP headers
app.use(helmet());

// Vulnerable endpoint: echoes user input without sanitization (potential XSS)
app.get('/vulnerable', (req, res) => {
  const userInput = req.query.input || '';
  res.send(`User input: ${userInput}`);
});

app.listen(3000, () => {
  console.log('Server running on http://localhost:3000');
});

In this Express example, the /vulnerable route echoes a query parameter without sanitization, creating a simple Cross-Site Scripting (XSS) vulnerability. SmartScanner can detect this issue along with other security gaps like missing headers or weak configurations.

If you're diving deep into Express security, don’t miss our guides:

2. Boosting Security in Your NestJS App

NestJS gives you a structured way to build scalable apps, but you still need to watch out for security pitfalls. Consider this simple NestJS controller:

import { Controller, Get } from '@nestjs/common';

@Controller('users')
export class UsersController {
  @Get()
  findAll(): string {
    return 'This action returns all users';
  }
}

Once deployed, running SmartScanner on your NestJS endpoint helps catch misconfigurations or overlooked vulnerabilities in your controllers and middleware.

3. Securing Your NextJS Project

NextJS is awesome for both server-side rendering and static sites, but it also mixes server and client code. Here’s a simple NextJS API route:

// pages/api/hello.js
export default function handler(req, res) {
  res.status(200).json({ message: 'Hello, secure world!' });
}

SmartScanner will scan this endpoint to ensure that your full-stack project is secure from both server-side and client-side vulnerabilities.

Best Practices for Node.js Security

While SmartScanner is a great tool, here are some extra tips to help you keep your app secure:

Keep Dependencies Updated:

Use tools like npm audit to spot and fix vulnerable packages.
Validate User Inputs:

Always sanitize and validate data to block injection attacks.
Secure Sensitive Data:

Use environment variables for API keys and credentials—never hardcode them.
Use Security Middleware:

Libraries like Helmet can help set secure HTTP headers automatically.
Practice Least Privilege:

Limit access rights to only what’s necessary for each part of your app.

Wrap-Up

Security isn’t just a checklist—it’s an ongoing part of building awesome Node.js applications. By incorporating SmartScanner into both your code testing and your development workflow, you're not only catching vulnerabilities early but also fostering a security-first culture on your team.

So, fire up your server, integrate SmartScanner into your CI/CD pipeline, and keep your Node.js apps secure and running smoothly. Happy coding and stay secure!

Should I Hide My Admin Login Page? Yes, You Should!

SmartScanner — Mon, 16 Sep 2024 09:00:00 +0000

As a web application owner, you might be wondering whether hiding your login page is necessary. The short answer is: Yes, you should hide your admin login page! However, this only applies to admin interface login pages and not user login pages.

In this article, we’ll explore why protecting your admin login page is crucial, the risks of leaving it exposed, and effective measures to safeguard it from potential attacks.

What is an Admin Interface?

Most web applications provide an interface for administrators to manage critical aspects of the site, such as content updates, user management, and system configurations. These interfaces enable essential tasks, such as:

Changing website content or adding new pages.
Modifying user roles and permissions.
Managing product listings or prices (e.g., for e-commerce websites).
Monitoring system logs or application performance.

There are various ways these administrative tasks can be carried out. Common methods include:

Remote management protocols like SSH, PowerShell, RDP, or VNC.
Code and configuration files for direct control over the system.
APIs that expose management functionality.
Browser-based admin panels accessible via web consoles.

In this article, we’ll focus on browser-based admin panels, the most common and vulnerable admin interface.

Why Exposed Admin Interfaces are a Major Risk

An exposed admin login page is a goldmine for hackers, offering a direct gateway to the heart of your website’s functionality and sensitive data. Many websites use default or easily guessable URLs for admin login pages, such as /admin/ or /administrator/. Once hackers locate these pages, they can exploit vulnerabilities through attacks like:

Brute force attacks: Repeated attempts to guess passwords.
SQL injections: Injecting malicious code to manipulate the database.
Session hijacking or redirection: Taking over admin sessions.

Leaving your admin interface exposed is equivalent to leaving the front door of your house unlocked. But, by following certain security practices, you can significantly reduce the chances of a breach.

How to Protect Your Admin Interfaces

Here are several actionable steps you can take to enhance the security of your administration panels:

1. Separate Admin and User Interfaces

Separate the standard user interface from the admin interface. This ensures that you can apply stricter security measures on the admin side without affecting user access. Hackers targeting user login pages won’t immediately have access to the administrative backend.

2. Do Not Expose the Admin Interface on the Public Internet

Wherever possible, avoid exposing your admin panel directly on the internet. One option is to restrict access to the admin interface through a VPN or require physical network access. Alternatively, you can implement a whitelisting mechanism to limit access to specific IP addresses, drastically reducing the likelihood of unauthorized access.

3. Use HTTPS for Secure Communication

Always use HTTPS to encrypt traffic between your admin panel and the client (browser). This prevents eavesdropping and protects admin credentials from being intercepted. Without HTTPS, attackers can easily capture sensitive information through a man-in-the-middle (MITM) attack.

4. Enforce Strong Password Policies

Brute force attacks are one of the most common methods used to compromise login pages. Enforce a strong password policy with complexity requirements (e.g., a mix of uppercase, lowercase, numbers, and special characters). Additionally, implement CAPTCHA and account lockout mechanisms to prevent automated password-guessing attempts.

5. Implement Multi-Factor Authentication (MFA)

Multi-factor authentication (MFA) provides an extra layer of security by requiring users to verify their identity through multiple factors—something they know (password), something they have (an OTP or security token), or something they are (biometric verification). MFA helps prevent unauthorized access, even if passwords are compromised.

6. Log and Monitor Admin Activities

Enable detailed logging and monitoring of admin activities. This allows you to track login attempts, suspicious behavior, or changes made in the admin panel. By actively monitoring these logs, you can detect and respond to potential threats in real-time, reducing the chances of an undetected breach.

7. Obscure the Admin URL

If you must expose your admin interface to the internet, consider obscuring the URL. Instead of using predictable paths like /admin/, choose a non-standard, hard-to-guess URL (e.g., /secret-dashboard-6421/). This practice, called security through obscurity, is not a foolproof solution but can reduce the chances of automated or low-effort attacks.

Note: While obscuring URLs can help, it should not be your only defense. Hackers can still discover these URLs through more sophisticated methods.

8. Regularly Test and Secure Your Admin Interface

Regular security testing is crucial to keeping your admin interface secure. Use a web application security scanner to scan for vulnerabilities such as outdated software, improper permissions, directory listings, or weak configurations. For example, a missing referrer policy could unintentionally leak your admin URLs in outgoing requests. Fixing these vulnerabilities can prevent hackers from exploiting them.

Conclusion

Hiding your admin login page is a simple but effective step in reducing your website’s risk of being compromised. However, obscuring the URL is just the beginning. By following the comprehensive guidelines outlined in this article, you can significantly strengthen the security of your admin interface.

From using HTTPS and strong passwords to implementing multi-factor authentication and regular security scans, these actions will help protect your website from malicious attacks.

Remember: Security is an ongoing process, not a one-time task. Continuously scan and fix any vulnerabilities in your web application to stay ahead of evolving threats.

To help with this, you can download and use SmartScanner, a web application security scanner, to test your website for vulnerabilities — completely free of charge. Don’t wait until it’s too late, secure your website now!

Online Robots.txt Validator For Creating a Secure Robots.txt

SmartScanner — Tue, 31 Oct 2023 21:04:56 +0000

A robots.txt file is a small but important part of a website. It is a plain text file that is placed in the root directory of a website and is used to communicate with search engine crawlers, telling them which pages or sections of a site should or should not be indexed.

TLDR

Use the online robots.txt validator to make sure your robots.txt is well formatted and has no security risk.

The robots.txt file is a set of instructions that tell web crawlers which parts of a website they are allowed to access. These web crawlers are automated programs that scan websites to gather information about the pages and content on a site. While these crawlers can help index a website and make it more visible in search engine results, they can also consume a lot of server resources and bandwidth if they are not properly managed. Not every robot out there is good. That's why having a properly written robots.txt file is very important.

The structure of a robots.txt file is relatively simple but it is also hard to debug and make sure it's working as expected. But with our new online tool for validating robots.txt it's easy to create one.

You can simply copy and paste your robots.txt contents into this tool and check possible errors. Then you can easily fix the problems with recommendations provided for each issue.

Security Issues in Robots.txt

There's a misunderstanding that a robots.txt file can be used for protecting sensitive files on a website. That's why many websites disclose valuable information to hackers. One benefit of our online robots.txt checker is that it can also check for security-related problems in robots.txt.

The online robots.txt validator can detect up to 19 problems. In the following, we explain some common security vulnerabilities that can be found in a robots.txt file.

File Disclosure in Disallow

It happens when you add a disallow record with a full file path.
The robots.txt is a voluntary mechanism. It's not sufficient to guarantee some robots will not visit restricted URLs. In fact, malicious users can use robots.txt to find out the resources you are trying to hide; like a login page.

How to Fix

You should not use the disallow rule for protecting files. Following are some alternatives:

Use strong authentication: For sensitive resources on your website you must use strong authentication and access control mechanisms.
You don't need to disallow at all: If the file in the disallow rule is not linked to your website, you don't need a disallow for it.
Use noindex meta tag: If you only want to prevent search engines from indexing your URL, you can use the noindex ruleset. noindex is a rule set with either a <meta> tag or HTTP response header and is used to prevent indexing content by search engines that support the noindex rule, such as Google.
Use pattern: Instead of revealing the full path, use patterns in the disallow rule. for example, use disallow: /*.php to exclude all php file

Directory Disclosure in Disallow

Revealing directories like /admin/ in the disallow rule gives hackers a clue to start digging in that directory.

How to Prevent

In addition to the above recommendations, you should make sure directory listing is disabled on your website.

Possible Path Disclosure in Allow

By revealing URLs in the allow rule, you disclose resources to malicious users. You must make sure these URLs are not sensitive.

How to Avoid

Make sure you're not revealing any sensitive resources.
Make sure revealed folders do not display a directory listing.

A robots.txt file is a vital aspect of website management and by properly configuring it, website owners can protect sensitive information and ensure that their site is effectively managed.

Go ahead and test your robots.txt now.

Web Scanner, A Must Have Tool For Web Developers

SmartScanner — Sat, 23 Sep 2023 18:51:32 +0000

A review about web scanners and how they can be a secret weapon to gain competitive advantage for developers.

As the internet grows and technology advances, web development has become more complex, and so has web security. Web developers must use tools that can help them ensure that their websites are secure. Let's see how using a web scanner can help with that.

Web Scanners in Developer's Toolset

Web development is a challenging job that requires a solid understanding of programming languages, web development frameworks, and emerging technologies. Web developers are responsible for different aspects of a web application, including interface design, information architecture, and website performance optimization. Collaboration with other developers, designers, and stakeholders can add extra complexity to the development process.

Web developers use various tools to create and maintain websites, including text editors, IDEs, version control systems, and testing frameworks. However, one tool that is often overlooked is a web scanner.

A web scanner is a tool that can detect security vulnerabilities in web applications. It is an essential tool for web developers to ensure website security.

Benefits of Using a Web Security Scanner For Developers

Web developers have numerous responsibilities, including the creation of secure applications. However, web security is a complex domain that requires a different skill set and extensive experience to become an expert. Security testing of web applications requires knowledge beyond web development. Using a web scanner can assist web developers in identifying and resolving security vulnerabilities.

Here are some benefits of using a web scanner for web developers.

It saves time and effort by quickly and accurately scanning websites, allowing developers to focus on other aspects of website development.
Web scanners can improve a developer's skills by exposing them to new vulnerabilities and best practices for resolving them.
It can boost productivity by automating much of the testing process, enabling developers to spend more time developing new features or improving existing ones.
Web scanners can also enhance a developer's reputation by demonstrating a commitment to website security.
It can help developers avoid legal issues by ensuring compliance with industry regulations and standards.
Web scanners can identify security issues before they become a problem, which is crucial because it is much easier and cheaper to fix security issues before they are exploited by hackers.
By using a web scanner, developers can improve user experience by identifying and fixing security issues that may affect the UX of a website.

How to Test Security of Your Web Application With a Web Scanner

Several types of security testing are commonly used to identify and address security vulnerabilities in web applications. Penetration Testing, Source Code Analysis, and Vulnerability Scanning are common types of security testing. Manually conducting these tests requires a lot of knowledge and experience. If you're not a security expert, you can still perform security testing of your web application. All you need is the right tool. For instance, you can use a web scanner or a DAST tool.

DAST stands for Dynamic Application Security Testing, which is a type of security testing that involves testing the security of an application while it is running in a live environment.

There are many Web Scanners that can do a DAST on your website. Following is a list of top free web scanners.

OWASP ZAP: Free and open source. Actively maintained by a dedicated international team of volunteers.
Vega: Web security testing platform to test the security of web applications.
Wapiti: Wapiti allows you to audit the security of your websites or web applications.
SmartScanner - Website Vulnerability Scanner: While other tools may not be as user-friendly, SmartScanner stands out for its simplicity and intuitive interface.

Using SmartScanner for Automated Web Security Test

SmartScanner is a DAST tool that scans websites for vulnerabilities and security issues. It uses Artificial Intelligence, passive scanning and active methods to identify security issues. SmartScanner can check for a range of security issues, including SQL injection, cross-site scripting (XSS), and other vulnerabilities.

SmartScanner is easy to use, and it automatically browses your application, navigates to different pages, runs JavaScripts, and fetches remote APIs to find web vulnerabilities. SmartScanner provides reports specific details for every vulnerability along with remediation and mitigation steps so you can fix vulnerabilities easily.

Download SmartScanner, scan your website, and discover your web security problems.

Secure Coding 101: How to Read and Write Files Securely

SmartScanner — Thu, 10 Aug 2023 06:58:00 +0000

Working with files is a common requirement in many applications, but it also introduces several potential security vulnerabilities. In this article, we will explore how to securely work with files in your application.

Let's review common vulnerabilities and mitigations when working file files.

TLDR

File Inclusions and Path Traversal vulnerabilities are the results of insecure accessing files
Avoid accessing file paths that are built with user-provided input
If you must use inputs from users in file paths, use a strict whitelist for allowed user inputs and reject non-compliant inputs
Use libraries to detect if the file you're going to access is in the intended directory (e.g. realpath() in PHP and NodeJs)
When creating files (e.g. file uploads) set a reasonable file size limit
When writing user-provided content, make sure the content type is what you expect
When creating files, make sure they don't have execution permission
When creating files, make sure they're not publicly accessible

File Inclusion Vulnerability

File inclusion vulnerability is a type of web vulnerability that occurs when an application allows a user to include a file in the output of a web page without properly validating or sanitizing the user input.

There are two types of file inclusion vulnerabilities: Local File Inclusion (LFI) and Remote File Inclusion (RFI).

LFI occurs when an attacker can include a file from the local file system of the server. This can allow the attacker to view sensitive files or execute arbitrary code on the server.

RFI occurs when an attacker can include a file from a remote server. This can allow the attacker to execute arbitrary code on the server or steal sensitive information.

For example, consider the following vulnerable PHP code:

$module = $_GET['module'];
include $module;

This code retrieves a value from the URL query string using the $_GET superglobal, specifically the "module" parameter. The retrieved value is then used as the file path to include a PHP file using the include statement. This means that the contents of the specified file will be included in the current script at the point where the include statement appears.

However, this code can be potentially dangerous to both LFI and RFI.

In the above PHP code example, a user can pass any file name or URL as the module parameter. For instance, an attacker can host a PHP script on their server and pass its URL, like http://attackerhost/phpscript.txt, in the module parameter and execute arbitrary commands on the target system.

In PHP, for example, file inclusion vulnerabilities are often caused by the use of the include or require functions without proper input validation. Similarly, in JSP, file inclusion vulnerabilities can occur when the include or jsp:include tags are used without proper input validation. Using Server.Execute or Server.Transfer in ASP also can create file inclusion vulnerabilities.

Local File Download

Suppose an application has a file download functionality that allows users to download a file from the server. The application takes a file name as a parameter and returns the file contents to the user. If the application does not validate the file name parameter and allows users to download any file on the server, an attacker can exploit this vulnerability by passing a sensitive file name as the parameter. This is called Local File Download or Local File Disclosure vulnerability.

In our example, if the user passes /etc/passwd as a module parameter, the content of passwd file is displayed to the user.

Local file download is a very common vulnerability and can be found in any programming language.

Prevent File Inclusion Vulnerabilities

Follow below best practices to mitigate File Inclusion vulnerabilities:

Do not include or open files that are built using user-provided data
If you must use inputs from users in file paths, use a strict whitelist for allowed user inputs and reject non-compliant inputs

Path Traversal Vulnerability

Path traversal vulnerability, also known as directory traversal vulnerability, is another web security vulnerability that allows attackers to access files outside of the intended directory. An attacker can exploit this vulnerability to access sensitive files, such as configuration files, password files, and even source code files.

This vulnerability occurs when you create file paths using invalidated user input. This allows the attacker to navigate to directories and files using the ../ character sequences. The ../ character sequences refer to the parent directory on file systems.

Consider below revised version of our vulnerable PHP code.

$module = $_GET['module'];
include './' . $module;

By prefixing the module variable with ./ character sequences, we're limiting file inclusion to the current directory only. So users cannot pass absolute file names like /etc/passwd or URLs that will eliminate RFI. But the user can enter ../../../../../../../etc/passwd as module parameter value and the final file path would resolve to /etc/passwd. This will reveal the contents of the passwd file.

The Path traversal vulnerability can occur in any programming language and also in Windows operating systems.

Prevent Path Traversal Vulnerability

Do not include or open files that are built using user-provided data
If you must use inputs from users in file paths, use a strict whitelist for allowed user inputs and reject non-compliant inputs
Use libraries to detect if the file you're going to access is in the intended directory (e.g. realpath() in PHP and NodeJs)

File Upload Vulnerability

When it comes to uploading files, security is paramount. Unfortunately, there is a severe vulnerability called arbitrary file upload that can compromise your data. This vulnerability allows users to upload any type of file, including scripts like PHP, Python, or ASP code, which can execute any command on your server.

In addition to arbitrary file upload, insecure file upload functionality can also introduce other vulnerabilities like Denial of Service (DoS) attacks. For example, if you don't set a limit on the file size that can be uploaded, an attacker could upload an excessively large file and potentially cause a DoS attack or consume excessive server resources.

Furthermore, insecure file uploads can allow attackers to override sensitive files using path traversal or upload malware to your server.

Prevent Insecure File Uploads

To prevent file upload vulnerabilities from happening, implement the following measures:

Set a reasonable file size limit and validate that uploaded files are within that limit.
Validate that uploaded files are of the expected file type and reject any files that are not.
Use randomly generated file names for storing uploaded files. If you have to use user-provided filenames, use a white list filter for accepted file names and reject other file names.
Use reputable anti-virus or malware detection software to scan uploaded files before they are processed or stored on your server.
Make sure uploaded files do not have execution permission.
Make sure only required users have access to the uploaded files.

Check out SmartScanner website for a Free Vulnerability Scanner

Secure Coding 101: How to Use Random Function

SmartScanner — Wed, 10 May 2023 07:50:30 +0000

Random numbers are everywhere on the web, and your security depends on them. Let's see if you're using them right.

Random numbers play a critical role in web application security. They are used in session identifiers, passwords, cryptographic keys, and more. However, if not implemented securely, they can lead to vulnerabilities that attackers can exploit to gain unauthorized access to sensitive information.

TLDR

Most random generators are not really random. They use math that looks random
Do not use Math.random() in JavaScript or random in Python
Use Web Crypto API in JavaScript, crypto module in NodeJs, and secrets in python
Do not try to implement your own random generation algorithm
Incorrect usage of secure random numbers can make your application vulnerable

How Random Functions work

There are two main types of Random Number Generators (RNGs): pseudo-random number generators (PRNGs) and true random number generators (TRNGs).

Pseudo-random Number Generators (PRNGs)

PRNGs are the most commonly used type of RNGs. They work by using an algorithm to generate a sequence of numbers that appear to be random. The algorithm takes an initial value as input and produces a series of numbers based on it.

The common algorithms used in PRNGs are the Mersenne-Twister and linear congruential generator (LCG).

These algorithms get an initial number called seed. They change it by adding previous random number, shifting, and doing XOR operators to generate the output. The output looks like a random number though it's just an output of a formula.

If you keep executing any PRNG, it will eventually generate the same numbers over and over. Any PRNG has a fixed length of numbers that can generate before starting over.

True Random Number Generators (TRNGs)

TRNGs generate truly random numbers based on physical processes that are inherently random. These processes include atmospheric noise, radioactive decay, and thermal noise. TRNGs measure the physical process and convert it into a random number.

Random Function Vulnerabilities

The seed and random number generation algorithm both can have weaknesses.

Prediction

You can say predictability is the main vulnerability of weak random number generators. PRNGs are inherently predictable as they are based on a mathematical formula. So if you know the seed and last random number, you can predict the next random number. This can lead to severe vulnerabilities.

For example, consider a forget password functionality that words based on a random token. If the token can be predicted, an attacker can reset the password of any user.

Collision

Besides the predictability, Some random generators that have low quality produce duplicate values very often. This can increase the risk of collision.

Consider an application that generates random session tokens for its users. The chances of producing duplicate session tokens are related to two factors:

Size of random space (length of session token)
Quality of the random selection

Short-length tokens will have a higher chance of collisions. And bad random generator does not generate all possible values. This can lead to vulnerabilities where a user can see another user's data.

Seed Leakage or Manipulation

Another vulnerability related to random number generators is choosing a weak seed. PRNG always generates the same sequence of numbers with the same initial seed value. If an attacker can find the used seed or manipulate it, he can easily generate same random numbers.

In pratice, hackers use different methods to predict the next random number. Some methods may involve statistical analysis, while others may involve reverse-engineering the generator's algorithm.

How to Use Secure Random Numbers

Using cryptographically secure random number generation algorithms is the key to securely producing random numbers. These algorithms generate random numbers that are unpredictable and cannot be easily guessed by attackers. The output of these algorithms is resistant to brute-force attacks, and it's statistically robust.
You should not try to implement your own one unless you know what you are doing. Instead, always use known to be secure random libraries.

Let's see a few examples of using secure random libraries in different programming languages.

Javascript

The Math.random() function is not suitable for cryptographic purposes, as it is not truly random and can be predicted or manipulated by an attacker.

To generate a secure random number in JavaScript, you can use the Web Crypto API. The Crypto.getRandomValues() method lets you get cryptographically strong random values. Here is an example code that generates a secure random number:

function generateRandomNumber() {  
  const array = new Uint32Array(1); // Create a 32-bit unsigned integer array  
  window.crypto.getRandomValues(array); // Fill the array with random values  
  return array[0]; // Return the first element of the array as the random number  
}  
 
console.log(generateRandomNumber()); // Output a random number between 0 and 4294967295

NodeJS

In NodeJS, the crypto module can be used to generate cryptographically secure random numbers. The following code sample illustrates the use of crypto module in generating a random number:

const crypto = require('crypto');  
 
function generateRandomNumber() {  
  const randomBytes = crypto.randomBytes(4); // Generate 4 random bytes  
  const hexValue = randomBytes.toString('hex'); // Convert the bytes to a hex string  
  const intValue = parseInt(hexValue, 16); // Convert the hex string to an integer  
  return intValue;  
}  
 
console.log(generateRandomNumber()); // Output a random number between 0 and 4294967295

Python

In Python, the random module can be used to generate random numbers. However, it is not cryptographically secure. Instead, you can use the secrets module to generate cryptographically secure random numbers. The following code sample illustrates the use of secrets module in generating a random number:

import secrets  
 
def generate_random_number():  
    random_number = secrets.randbits(32) # Generate a 32-bit random number  
    return random_number  
 
print(generate_random_number()) # Output a random number between 0 and 4294967295

Conclusion

Random numbers in computers are mathematical formulas and predictable. Not every random number generator is suitable for cryptography and security usage. Random numbers are just one element in security system design and implementation. There are many other things like seed generation, key management, and overall security system design that are extremely important and hard to get right. The Crypto 101 is a great place to start learning more about cryptography.

Read more on SmartScanner Security Blog.

3 reasons why any website's security is important

SmartScanner — Mon, 09 Jan 2023 11:53:24 +0000

You might think that security is important but only for big companies. This article is going to change your mind.

Hacked website can affect your audience

Security is critical as long as you have any visitor on your website (actually, security is vital even if you don't have any visitor at all, you'll see!).

Either recruiters on your personal project portfolio website or customers on your online shopping platform, it doesn't matter who you are targeting on your website. Any of your website visitors can be targeted by hackers as well if you don't make your website secure.

Your website can have many vulnerabilities, and any of them would be sufficient for hackers to compromise your website to use it against your visitors. Security vulnerabilities like XSS, SQLI or File Inclusions allow hackers to take control over what your visitors see on your website. These vulnerabilities can exist on any page, or they might be in your web server's configurations or even in an outdated WordPress plugin.

Why should hackers hack my website?

Hackers take over your website to do any of below malicious tasks.

Distributing malwares
Stealing your customers data
Making your web server a zombie and using it in DDOS attacks against other targets
Mining cryptocurrencies using your web server or your visitor's CPU power
Using your servers for running software like proxy or spammers.

You can see that even if no one visits your website, security is still essential because hackers can abuse your web server against inocent targets. Or, you might receive a costly bill from your hosting service because a hacker is using too much CPU power on your server to mine cryptocurrencies.

Reputation loss

You run a website for a reason. It could be revenue, finding a job or being creative. A hacked website impacts your reputation. Bad reputations results in less visitors, less trust and less revenue or job interviews.

Besides, not having a secure website has negative SEO impact. Google and other search engines penalize websites without SSL Certificate. If your site has no HTTPS and your competition does, Google punishes your websites, and your competitor website come up higher on Google search results than you are. Google Chrome also displays a red "Not secure" note in address bar for sites without SSL.

Hacked website is a thread to visitors, so it's no surprise to see that Google removes hacked website from search results.

When your website gets hacked, it can be added to specific black-lists like Google Safe Browsing list. The Safe Browsing lists—also referred to as threat lists or simply lists—are Google's constantly updated lists of unsafe web resources. Many applications like browsers use these lists to prevent users from accessing a hacked website.

If your visitors get warned about security of your website, the chances are extremely low that they will buy on your website, invite you to interview or visit your site anyhow.

Prevention is better than cure

OK, you got hacked! Now you have to clean up your website, restore your backup, remove your website from black-lists and inform your users. You lost your customers and revenue untill you've rebuilt the trust and reputation. That's a enormous task to recover from a security incident, and it will cost you time and money.

In most cases recovery and fixing a hacked website is a complex task that requires experts to do it manually, and of course it will not be for free.

How vulnerable is your website?

Hackers look for low hanging fruits. They look for high risk vulnerabilities in many websites (because any website can be usefull). Read more about hacker methods on how hackers hack article.

Good news is you can be like hackers. You can find holes in your website before hackers find them.

Testing security of your website is easy. There are dozen of web security testing tools out there you can use for free. Arachni and w3af are famous open source security scanners you can use.

SmartScanner is an AI powered web security scanner aimed to be easy to use for everyone. Download and enter your website address for a free scan to find out about security of your website.

Update Cheat Sheet for Developers

SmartScanner — Sun, 18 Sep 2022 09:24:25 +0000

This is a cheat sheet for updating critical web software.

Using an outdated application is a high-risk vulnerability that has an easy fix. This guide provides easy-to-follow instructions for different applications to fix security vulnerabilities.

⚠️ The goal of this guide is to eliminate vulnerabilities by updating applications. Sometimes updates can break things or lead to unexpected behaviors. It is up to you to perform enough checking and testing before using commands in this cheat sheet in the production environment.

RHEL/CentOS/Oracle Linux

Run below command in terminal (ssh)

sudo yum update

Debian/Ubuntu Linux

Run below command in terminal (ssh)

sudo apt update && sudo apt upgrade

OpenSUSE/SUSE Linux

Run below command in terminal (ssh)

sudo zypper up

NodeJs (npm)

Run the below command in your NodeJs project directory.

npm audit fix

Note that some vulnerabilities cannot be fixed automatically and will require manual intervention or review.
Some fixes can be forced using the below command but please make sure it doesn't break anything in your project.

npm audit fix --force

Python (pip)

You have to update packages one by one. Run the below command to get a list of outdated packages.

pip list --outdated

For each package run the below command to update it.

pip install [package_name] --upgrade

NuGet

From the command line, you can update packages in the solution to the latest version available from nuget.org.

nuget update YourSolution.sln

Note that this will not run any PowerShell scripts in any NuGet packages.

From within Visual Studio, you can use the Package Manager Console to also update the packages. This has the benefit that any PowerShell scripts will be run as part of the update whereas using NuGet.exe will not run them. The following command will update all packages in every project to the latest version available from nuget.org.

Update-Package

PHP (Composer)

Navigate to the root of your application, where your composer.json file is, and run the below command.

php composer.phar update

In Windows:

composer update

Go (golang)

To update all packages in your GOPATH, run the below command.

go get -u all

Ruby (gem)

To update all gems:

gem update

RubyGems keeps old versions of gems. Run cleanup to remove old gems after an update.

gem cleanup

Maven (mvn)

Run the below command to force an update of dependencies.

mvn clean install -U

Rust (cargo)

For updating all dependencies of your Rust project, you need to install a third-party crate. Install cargo-update:

cargo install cargo-update

Then run the below command to check for newer versions and update all installed packages.

cargo install-update -a

WordPress

WordPress lets you update with the click of a button. You can launch the update by clicking the link in the new version banner (if it’s there) or by going to the Dashboard > Updates screen. Once you are on the “Update WordPress” page, click the button “Update Now” to start the process off. You shouldn’t need to do anything else and, once it’s finished, you will be up-to-date.

Windows

Run the below command on cmd to open the Windows update screen.

control update

You can use SmartScanner for finding outdated components in your application.

References

CSRF, XXE, and 12 Other Security Acronyms Explained

SmartScanner — Tue, 12 Jul 2022 08:59:30 +0000

Acronyms are shortcuts, and we love using them, specially the catchy ones! Let's decipher some commonly used acronyms in the cyber security industry.

OWASP

The Open Web Application Security Project (OWASP) is a nonprofit foundation that works to improve the security of software. The OWASP Top 10 is one their popular projects.

XSS

It stands for Cross-Site Scripting. An X is used instead of the C to prevent confusion with Cascading Style Sheets (CSS).

Read more about Cross-Site Scripting vulnerability

SQLI

SQL Injection, is an attack where the SQL commands used in an application are manipulated by attacker. SQLI is a dangerous and common vulnerability. Find SQL Injection on your website with SmartScanner now.

Read more about SQL Injection vulnerability

RCE

Remote Command Execution (RCE) is a high-risk vulnerability. It can occur anywhere from routers to online shops. By exploiting RCE, an attacker can execute commands (usually OS commands) on the target system.

Read more about Remote Command Execution vulnerability

DoS and DDos

Denial of Service (DoS) is a famous security acronym. You might have heard it at the news. DoS is a type of attack that makes the target service unavailable. Attackers usually perform DoS attacks by sending enormous traffic to the target.

Distributed Denial of Service (DDoS) is a DoS attack from many different sources. This type of DoS typically runs using zombie botnets.

CSRF

CSRF (pronounce Sea Surf) stands for Cross-Site Request Forgery. CSRF (aka XSRF) is an attack where the attacker sends a request on behalf of a victim user without her knowledge. Attackers exploit CSRF to do actions using the victim's permission. For example, a hacker can create an admin user for himself using a CSRF attack.

XXE

An XML External Entity attack is a kind of attack against an application that parses XML input. In this attack, the vulnerable application processes a reference to an external entity in the provided XML. The XXE is a dangerous attack that can lead to information disclosure or denial of service attacks.

SSRF

In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources.

SSI

A Server-Side Includes Injection is a type of security attack that exploits the Service-side Includes features of a web server. The Server-side includes are tags in HTML files. The web server executes these tags to add dynamic contents to the page before sending it to the user.

RFI

Remote File Inclusion (RFI) occurs when the web application downloads and executes a remote file. This remote file is usually controlled by an attacker and is passed as a request parameter.

Read more about Remote File Inclusion vulnerability

LFI / LFD

Local File Inclusion (LFI) is similar to a remote file inclusion vulnerability, but only local files on the server can be included for execution. It does not mean the LFI is less dangerous than RFI.

When the local file is only opened and sent back to the user (or attacker), it is called Local File Download or Disclosure.

Read more about Local File Inclusion

IDOR

IDOR stands for Insecure Direct Object Reference. It is a vulnerability that occurs when a reference to an internal object, such as a file or directory, is retrieved from user-supplied input. If no proper authorization is implemented, an attacker can abuse this reference to access every object.

CVE

The Common Vulnerabilities and Exposures (CVE) system provides a mechanism for referencing publicly known security vulnerabilities.

CWE

The Common Weakness Enumeration (CWE) is a category system for hardware and software weaknesses and vulnerabilities.

10 Secure Coding Best Practices to Follow in Every Project

SmartScanner — Sat, 11 Jun 2022 09:57:01 +0000

Let's see how we can make more secure software.

Update, Update, Update!

Using vulnerable and outdated components with known vulnerabilities has always been in the OWASP Top 10 Application Security Risks. You can take a giant leap in securing your projects only if you use up-to-date tools and libraries.

Stick to Standards

If you have the Not invented here (NIH) syndrome, you prefer to develop everything from scratch. That's fine if you have the time and money to do so. But building major things like cryptography and web servers from scratch needs a lot of skills and effort. Such complex components cannot be built by a single person. Even if you have made one, you should not use it in production without in-depth reviews from many other people.

In design and architecture concepts, you should do the same. You should follow best practices to benefit from the community experience.

Next time instead of introducing your own hash algorithm, use one of the well-known hash functions implemented by an open-source and peer-reviewed library.

Use Trustworthy Packages

One significant risk of using third-party modules (like packages in npm, PyPI, NuGet, etc. ) is the Supply Chain Attack. Consider one of your project's dependencies goes rogue and doesn't do what it was supposed to do. It is called a supply chain attack. This has happened for popular npm packages (UA-Parser-JS, COA, and RC), and it can happen for many others.

We know that using third-party packages is inevitable. So, here are a few tips to consider before choosing a third-party library.

Prefer packages with more contributions (more contributors, commits, pull requests, and stars)
Prefer packages with less open issues
Prefer packages with higher release frequency
Use dependency scanners like GitHub Dependabot to find vulnerable packages.

Never Trust User

Always validate data received from user input before processing them. Check the length, type, allowed characters, and data pattern before using it.

The essential thing in user validation is to do it where the user cannot manipulate the logic. For example, the user has complete control over a webpage, so checking if the user entered a correct email address on the client is not enough, and you should validate it on the back-end again.

Always Encode Output

Always use proper encoding when displaying data to the user. The encoding depends on the context you display the data within.
For example, data on a web page should be HTML-Encoded, and data in URL should be URL-Encoded. Other contexts like CSV, XML, JSON files, or email need unique encodings.

Catch Exceptions

Exceptions happen! We should be prepared for them. Unhandled errors create security issues like failing insecurely or revealing sensitive information.

Always assume things will break eventually and get prepared for it.

Do not Write Secrets in Comments

When you put comments in the code, it means your code is not clear and expressive enough and needs explanation. So, a better title for this section would be Do not Write Comments.

“Comments are always failures.”
— Robert C. Martin @ Clean Code

There are some valid use-cases for comments in the code, but writing operational information and sensitive data like passwords are not one of them.

Use Linter

Linters can analyze your code and enforce particular rules. Linters assist you in finding errors, bugs, code smells, and suspicious expressions like using eval and dangerous regular expressions.

Possess an Open-Source Spirit

Open source projects are maintained by the community. It means their structure is not specific to a single user's environment. Open source projects (usually) don't have any hard-coded passwords or internal IP addresses. These are good practices we can follow in our projects.

Not every project is supposed to be open-source and publicly available. But we should prepare all projects for open sourcing. Here are a few things to start:

Remove hard-coded passwords, IP addresses, and database connection strings, ...
Load all configurations from environment variables
Add a readme.md file to your project and document build and test instructions.

Write Clean Code

A clean code is inherently more secure. From a security point of view, a clear code has many benefits:

A clear code has fewer opportunities for vulnerabilities to occur because they're less complex
Reviewing and finding vulnerabilities in a clear code is easier
It takes less time and effort to fix a vulnerability in a clear code

You can read the Clean Code book (if you haven't read it already) and start refactoring your codes.

Serverless Application is not as secure as you might think!

SmartScanner — Sat, 21 May 2022 11:08:54 +0000

What is a Serverless Application?

For running a traditional web application, you need to set up an OS, configure a web server, install a CMS and prepare a database. You should take care of infrastructure, capacity, and maintenance of servers as long as your application is running.

What if you could only focus on developing your application and don't think about the infrastructure? This is exactly what you can do in a Serverless architecture. You write your code and publish it on cloud servers like AWS Lambda, Cloudflare workers, or Google Cloud Functions. Your code will run on cloud servers, and your cloud provider manages and handles the infrastructure and maintenance.

Cloud companies that provide Serverless services offer different form of it. Take FaaS as an example. In this development model, cloud providers allow you to write your application in small separate functions. That's why this service is called Function as a service (FaaS). This approach supports trending architectures like the JAMstack (JavaScript, API & Markup). The JAMStack consists of static pages (the Markup) that integrate with the backend through the use of APIs in Serverless applications.

💡 PaaS is also another Serverless cloud service where you control the entire application. This is in contrast with FaaS that has an event-driven architecture. In FaaS, your application (function) gets executed in certain events like incoming requests.

Serverless Security

The Serverless development model has many benefits like cost efficiency, elasticity, and productivity. But Serverless applications are not more secure compared to traditional applications. Cloud providers like Amazon AWS take care of OS and platform vulnerabilities, but you don't have access to the servers, and you can't use classic security solutions like IDS/IPS that require installation on endpoints.

Further, in a Serverless architecture, the entire application consists of more small components, that means more entry points resulting in an increased attack surface.

Developing and running a Serverless application depends on the cloud provider's standards. This means the same code can not be used in another cloud provider without change.

Privacy is another concern in Serverless applications because of using shared resources and access by external employees in public Serverless cloud infrastructure.

Vulnerabilities in Serverless Applications

Security vulnerabilities affect different layers of any application like OS, web server, database, and the application itself. In Serverless architectures, the cloud provider takes care of all infrastructure security. So you won't worry about security misconfigurations and issues like Outdated server vulnerability. But the application security is still your responsibility in the Serverless development model. And unfortunately, many vulnerabilities relate to the application layer. Vulnerabilities like:

SQL Injection
Cross-Site Scripting (XSS)
File Inclusion Vulnerabilities
Cross-site Request Forgery (CSRF)
Using eval and Command Execution
Unvalidated Redirects and Forwards

These are generic vulnerabilities that are in OWASP's Top 10 list. We have covered some of them in articles like common web vulnerabilities and securing your NodeJs express application. In the followings, we will review vulnerabilities that are less known but more specific to Serverless applications.

Missing Function Level Access Control

Sensitive functionalities should be protected with an authentication mechanism. It doesn't matter whether these functionalities are served as web pages or an API. If anyone can access such functionalities, this is a broken access control flaw.

All administration use-cases are prone to this issue. You might have several Serverless APIs for tasks like managing accounts/posts or changing service status. You should make sure that only allowed users can access and use such functionalities.

Sensitive Data Exposure

Let's say you have a Serverless application for a voting system. One function of this platform is to show the vote counts for any candidate. Consider a Serverless function for displaying vote counts which accepts candidate ID and returns a list of every user who has voted for that candidate. So you can easily show the count of users as vote counts for the candidate.
But something's fishy here! We need a function to display vote counts, not to return name of voters! You might say that the list of users is not displayed anywhere, and only the count of users is represented. That's right, but as long as the Serverless function is returning all those information and it's publicly accessible, an attacker can abuse it.

Sensitive Data Exposure is a very common flaw. To avoid it you should return the minimum required data in your Serverless functions.

Insecure Direct Object Reference (IDOR)

Imagine an HR application that has a profile API that accepts an employee ID and returns the employee information. Let's say the employee IDs are an integer number and the Serverless function queries it on the database to find the employee. What could go wrong in this scenario? An attacker can build a collection of employee IDs by starting from 1 and incrementing to any number. Then this collection can be used to query your function to enumerate all employee information. This can happen if the API does not implement the proper access control we discussed earlier.

Here employee ID passed to the Serverless API is a reference to the employee record in the database. And this reference is directly controlled by the user. If such references are easy to guess, you risk your data being enumerated.

Avoid using guessable patterns for IDs (using hash can help). Make sure your functions have access control to mitigate IDOR flaws.

Template Language Injection

A common way of rendering HTML pages using a template is to evaluate an expression like 2+2 and display the results (4) in output. Template language injection or Expression language injection occurs when a user can change the expression used in the template.

Components with Known Vulnerabilities

Serverless applications are usually in JavaScript (or TypeScript) or Python languages. Developers in Python or JavaScript usually use numerous third-party packages for completing different tasks. These packages might have vulnerabilities, and using them can make your Serverless application vulnerable.

To mitigate component vulnerabilities, make sure you're using the updated version of any library and run security tests to find vulnerable packages.

💡 In NodeJs, you can use npm audit to find vulnerabilities in npm packages. Read Securing Your NodeJs JavaScript Project for details.

Conclusion

Serverless applications have many benefits and use cases like file transformation, providing dynamic contents, logging, and others. There's a misunderstanding that Serverless applications are more secure. This is true to some extent when it comes to OS vulnerabilities, but you need to take application layer security in your hand.

We reviewed some of the common vulnerabilities in Serverless applications, but you should know that these vulnerabilities are not complete and these are not even limited to Serverless applications. So security testing of your web applications is a crucial job for securing them.
Security of Serverless applications needs a DevSecOps solution where developers, operation team, and Security guys collaborate closely.