DEV Community: Ali-Abo-Alshamlat

Backend Security Risks and Tips on How to Prevent Them

Ali-Abo-Alshamlat — Sat, 20 Jan 2024 16:12:56 +0000

1. Data injection risks

Data injection is the use of queries to hack your web application servers. Cyber attackers initiate a query to your system to retrieve sensitive data. In the absence of measures in place to check the origin and authenticity of the query, your system blindly processes the query and provides the requested information to the attackers.

A great way to prevent data injection is to ensure that your backend applications don’t accept or process inputs from unauthorized and unverified sources. That way, requests from unverified sources will be blocked or go unattended.

2. Lack of authentication security

Web application backends consist of multiple services with authentication requirements, databases as well as console/OS level access have logins, and all of these services run directly on the operating system layer. Therefore, maintaining authentication security is crucial—otherwise, any vulnerability entering the system can lead to the whole operating system being compromised.

For example, when it comes to the web server, restricting logins to certain users or IP addresses, using HTTP authentication on development areas, or using automated brute force detection systems (that automatically ban offending IP addresses) helps a lot.

3. Lack of vulnerability scanning

Scanning for vulnerabilities is another neglected safeguard regarding web applications, from frontend to backend. Only when you scan will you know what is and isn't vulnerable.

Scanning is often thought of as a difficult and time consuming task, but modern tools have made it possible to scan automatically and with a low amount of effort. Using online vulnerability scanners and other tools like Nikto or OpenVAS helps you stay on top of your web application's safety by automatically scanning and generating reports for you to review.

4. Lack of encryption between frontend and backend

Communication between your web application's frontend and backend is what drives your web application. And this communication often goes over the internet unencrypted, as the software in use is often built without encryption in mind.

Man-in-the-middle-attacks apply not only between clients and web applications, but can also poison or steal requests from your frontend or backend, and transmit them to the attacker. While this is a more sophisticated type of attack, it's still quite possible for someone who wishes to target your web application.

Encrypting requests between the frontend and backend is a simple yet critical solution for preventing these attacks.

5. Lack of centralized log management

With multiple backends, services and distributed servers (sometimes even across different public/private clouds and access levels), modern web applications call for a centralized logging system, to which all services can write their log files.

This allows for further monitoring and logging of errors, unauthorized entry attempts (such as failed login alerts), and other information which can be used to improve performance as well.

A lack of centralized logging often leads to unnecessary privileges being made available to team members, or simply due to the scale of things, log files getting overlooked.

This can be particularly dangerous if the log files indicate attacks against your web application's backend, and their neglect means an attack isn't effectively blocked in time.

6. SSL misconfigurations and lack of monitoring

Using SSL certificates has become a norm for the modern internet. Most browsers and search engines give priority to websites with SSL certificates, and display various forms of alerts and errors when browsing websites with insecure, misconfigured or expired SSL certificates.

Be sure to monitor your SSL certificate and configure it correctly. Ensuring your certificates are valid is the first step, noting that they're set up with strong ciphers and that secure and modern TLS versions are in use on the server-side. This will go far in maintaining that your web application's backend is communicating securely with its frontend.

7. Sensitive data exposure

Applications often cache or hold data in temporary locations for customers to access. This data can be used to improve performance or simply allow users to download their files, but if data isn't removed in time—or isn't restricted to the specific customer—it can allow attackers to find and download this sensitive information.

For example, if a user uploads his avatar onto a web application, the web application stores it in a publicly accessible folder for the image to render. However, if the folder isn't well secured, an attacker can locate the folder and download all the user's avatars.

Securing folders and other publicly accessible information is a must. Also, performing self-scans by using Google Dorks enables you to quickly find public information crawled by search engines.

8. Outdated/end-of-life software components

Multiple software components are used to make any web application work, with web servers, databases and other software helping to improve performance.

With all these bits of software in use, the security of each individual application has to be considered.

For example, if your web server is vulnerable, it can cause your entire web application to be vulnerable—by accepting inputs from users which can expose sensitive areas of your web application.

As we shared in our 'Why software gets hacked' blog post, having any outdated or end-of-life software component on the public internet is a huge risk, especially with tools like Shodan available, allowing users to search for servers running specific versions of software. This can make you and your web application an easy target when running outdated and end-of-life software.

Front-End Security: Popular Types of Attacks

Ali-Abo-Alshamlat — Fri, 19 Jan 2024 17:07:19 +0000

1. Cross-site scripting (XSS) attacks

It is a type of attack that injects malicious client-side code. For example, an attacker could input JavaScript that steals user cookies into a comment form that doesn't sanitize entries. When victims load the compromised page, the script executes to give the attacker access to user accounts.

Clickjacking attacks

Clickjacking attacks rank as one of the largest types of attacks under the XSS attack umbrella, as they're simply performed by replacing legitimate parts of a web page with similar-looking, yet dangerous, elements. For example, checkout buttons can be replaced with buttons redirecting users to fake banking pages, legitimate download buttons can be replaced with buttons resulting in malware downloads, and more.

Geolocation stealing

With XSS attacks, an attacker can inject JavaScript libraries, which then execute on the client side—logging the user's IP address, geolocation and other personal details. These can then be used by the attacker to target the end user with personalized scams or phishing.

Cryptomining

With code injected by an XSS attack, cryptomining can be performed on end users' devices as well. While it may already seem to slow down a single device, hundreds or thousands of users visiting a web application every day means crypto mining scripts running on your web application can unknowingly cause not only slowdowns but also heating issues on users' devices. This sort of effect on your web application can lead to a negative experience on their part.

Protection against XSS attacks can be achieved by the proper sanitization of inputs made into your web application, as well as by filtering inputs correctly. For example, limiting mobile numbers to digits only or not allowing special characters in names can yield a substantial benefit by preventing most injection attacks on your web application.

2. DoS (denial-of-service) attacks & DDoS (distributed denial-of-service)

· DOS (Denial of Service) Attack: In this attack a computer sends a massive amount of traffic to a victim’s computer and shuts it down. Dos attack is an online attack that is used to make the website unavailable for its users when done on a website. This attack makes the server of a website that is connected to the internet by sending a large number of traffic to it.

· DDOS (Distributed Denial of Service) Attack: In this attack dos attacks are done from many different locations using many systems.

Types of DOS Attacks:

Buffer overflow attacks
Ping of Death or ICMP flood
Teardrop Attack
Flooding Attack

Types of DDOS Attacks:

Volumetric Attacks
Fragmentation Attacks
Application Layer Attacks
Protocol Attack.

3. Cross-site request forgery (CSRF):

These force victims to execute unwanted actions in an app they're logged into. For example, an attacker could trick users with a disguised link that quietly transfers funds from their account using their stored credentials.

For example, a user is logged into his banking application and browsing the internet at the same time. The user then comes across a "Download" button which he clicks on, and instead of actually downloading anything for the user, that fateful click transfers funds from the user's bank account to the attacker.

4. Content Security Policy (CSP)

A Content Security Policy (CSP) is a security standard that provides an additional layer of protection from cross-site scripting (XSS), clickjacking, and other code injection attacks. It is a defensive measure against any attacks that rely on executing malicious content in a trusted web context, or other attempts to circumvent the same-origin policy.

With CSP, you can limit which data sources are allowed by a web application, by defining the appropriate CSP directive in the HTTP response header.

5. Modern Frameworks

Often, web application front ends are built using commonly available frameworks. These frameworks make up the core of your web application frontend, and any security vulnerability within this framework can lead to a compromise of your web application as a whole.
Using modern and frequently updated frameworks can help boost your web applications security. These frameworks frequently include built-in authentication handlers and other security features that help standardize the security practises needed for your web application.

6. Incorporating security from the start

Web application development generally runs for months if not years. Developers come, developers go, budgets change, ideas change and projects change direction.

During all these changes, ensuring that your project stays secure is the most important aspect to consider. Incorporating a security-first approach in your project from the very start ensures that your project will stay secure no matter what changes come along, as seen in our previous interview Builders vs Breakers: Bridging the gap Between Software Development and InfoSec with Tanya Janca.

7. Auditing of 3rd-party libraries in use

3rd-party libraries are in use everywhere. They help speed up coding time and make implementation of new features into your web application that much easier—but any possible vulnerability in these 3rd-party libraries can impact your web application's overall security as well.

For example, many web applications rely on 3rd-party libraries for handling billing and customer purchases. Any vulnerability in these billing libraries can cause multiple security issues in your web application, such as the leaking of user information or redirecting users to phishing domains to capture card details.

Keeping track of and scanning 3rd-party libraries manually can often be tricky for large web applications, but online vulnerability scanners exist to help this process along, making it straightforward, automated, and ready to alert you whenever a vulnerability is found.

8. Ensuring CDN-pulled libraries undergo subresource integrity checks

Also critical is checking whether libraries loaded via 3rd-party CDNs are intact and untouched. Many web applications load libraries off 3rd-party CDNs for quicker loading of pages and better overall performance, but if these libraries are compromised via MITM attacks or if the CDN itself is compromised, it's possible to load bad code into your web application on the user side, leading to a poor experience.

For example:

<link href="https://cdn.jsdelivr.net/npm/bootstrap@5.0.0-beta2/dist/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-BmbxuPwQa2lc/FVzBcNJ7UAyJxM6wuqIj61tLrc4wSX0szH/Ev+nYRRuWlolflfl" crossorigin="anonymous">
The above code loads the popular Bootstrap CSS library but includes an integrity parameter with a checksum, which can be verified by your browser. This ensures that if the CDN is compromised and the CSS file is modified, the integrity checksum will not match and the file will not render in your user's browser.

At the expense of a poorly rendered page (at most), this will help protect your web application's reputation and security, while keeping your user safe as well.

Web simulation of Kali Linux

Ali-Abo-Alshamlat — Sun, 02 Oct 2022 10:18:49 +0000

This is a personal portfolio website of theme Kali Linux, made using React.js & tailwind CSS. If you want to edit this. Clone this project and edit the files in /src/components.
Link :
Source Code : (https://github.com/Ali-Abo-Alshamlat/ali-abo-alshamlat.github.io))
To run this on localhost type npm start and when u are done coding type npm run build to build your app.
NOTE: if you have yarn just replace npm start and npm run build with yarn start and yarn build.
To make the contact form work
Create a account in emailjs create also new Outlook or Gmail account to be able to send email.
Create a new service, select and log in to your newly created outlook or gmail account on EmailJS.
Go back to the dashboard and get the Service ID copy it.
Create a .env file in your root folder and put

NEXT_PUBLIC_USER_ID = 'YOUR_USER_ID'
NEXT_PUBLIC_TEMPLATE_ID = 'template_884mtzv'
NEXT_PUBLIC_SERVICE_ID = 'YOUR_SERVICE_ID'
into it. Replace *your user id and your service ID with your values in your EmailJS service.
This project was made using Create React App! Here is the scripts that u can run.
npm start
Runs the app in the development mode.
Open http://localhost:3000 to view it in the browser.
The page will reload if you make edits.
You will also see any lint errors in the console.
npm run build
Builds the app for production to the build folder.
It correctly bundles React in production mode and optimizes the build for the best performance.
The build is minified and the filenames include the hashes.
Your app is ready to be deployed!
See the section about deployment for more information.
Contributing
Contributions are what make the open source community such an amazing place to be learn, inspire, and create. Any contributiors who wants to make this website better can make contribution,which will be greatly appreciated.

Fork the Project
Create your Feature Branch (git checkout -b feature/AmazingFeature)
Commit your Changes (git commit -m 'Added some AmazingFeature')
Push to the Branch (git push origin feature/AmazingFeature)
Open a Pull Request