<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>security on toorun.dev</title><link>https://toorun.dev/tags/security/</link><description>Recent content in security on toorun.dev</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Wed, 20 May 2026 10:00:00 +0000</lastBuildDate><atom:link href="https://toorun.dev/tags/security/index.xml" rel="self" type="application/rss+xml"/><item><title>Command Injection in C/C++: Why system() with User Input is Dangerous (with Practical Examples)</title><link>https://toorun.dev/posts/command-injection-in-c/c-why-system-with-user-input-is-dangerous-with-practical-examples/</link><pubDate>Wed, 20 May 2026 10:00:00 +0000</pubDate><guid>https://toorun.dev/posts/command-injection-in-c/c-why-system-with-user-input-is-dangerous-with-practical-examples/</guid><description>Command Injection in C/C++: Why system() with User Input is Dangerous Command injection is one of the most common and dangerous security vulnerabilities in C/C++ applications—especially in Linux utilities, embedded systems, and IoT devices. This post explains what command injection is, why it happens, and how to avoid it, with practical examples and secure coding tips.
What is Command Injection? Command injection occurs when an application constructs a shell command using user input and executes it.</description></item><item><title>Embedded RED Cybersecurity Compliance (EN 18031): Requirements and Implementation</title><link>https://toorun.dev/posts/embedded-red-cybersecurity-en18031/</link><pubDate>Sat, 29 Mar 2025 12:30:00 +0000</pubDate><guid>https://toorun.dev/posts/embedded-red-cybersecurity-en18031/</guid><description>RED Cybersecurity (EN 18031) Overview The RED cybersecurity standard (EN 18031) defines requirements to ensure that radio equipment is secure and does not negatively impact networks, users, or services.
It is structured around three main articles:
3.3.d: Protection of networks and prevention of service degradation 3.3.e: Protection of personal data and privacy 3.3.f: Protection against fraud Applicability Depending on the system design, not all articles may apply.
Typical example:
Systems without user data → privacy requirements may not apply Systems without financial interaction → fraud-related requirements may not apply Network interaction → usually relevant and must be addressed Requirements Structure Each article is divided into:</description></item></channel></rss>