Category: information-security

Code Signing: Establishing Trust in Internet-Distributed Software

May 13, 2026

Code Signing addresses a core trust problem: how can users know that software downloaded from the internet is genuine and unmodified? By attaching a digital signature to executables, publishers assert both their identity and the integrity of the code.

How Code Signing Works

  1. Developer applies for a Code Signing certificate from a Certificate Authority (CA), submitting proof of identity.
  2. A public/private key pair is generated. The private key stays on the developer’s machine.
  3. At signing: code is hashed → hash encrypted with private key → signature block embedded in the executable.
  4. At verification: browser retrieves publisher certificate → decrypts digest with public key → rehashes code → compares. A match confirms authenticity and integrity.

Signable File Types (VeriSign Authenticode)

ExtensionType
.EXEExecutable programs
.CABCabinet files (installation packages)
.OCXActiveX controls
.DLLDynamic link libraries
.CATDigital thumbprint files

Limitations of Code Signing

  • Relies on the CA’s ability to verify applicant identity — fraudulent applications can yield valid certificates for malicious code.
  • A legitimately-signed program can still contain intentionally malicious logic.
  • Certificate Revocation Lists (CRLs) create a gap between key compromise and revocation.
  • Users must ultimately decide whom to trust.

SQL Injection: The Attack That Can Empty Your Entire Database

May 13, 2026

SQL Injection is one of the most prevalent web vulnerabilities. It involves passing crafted SQL commands through unsanitised input fields to interact directly with the backend database — potentially exposing, modifying, or deleting all data. Once exploited, it is equivalent to handing the attacker direct database access.

The Classic Bypass: ‘ or 1=1–

-- Normal authentication query:
SELECT * FROM users WHERE username='John' AND password='secret'
-- After injection of: ' or 1=1--
SELECT * FROM users WHERE username='John' AND password='' or 1=1--'
-- WHERE clause always TRUE → login bypassed

UNION Injection

SELECT header, txt FROM news
UNION ALL SELECT name, pass FROM members
-- Exposes all member credentials

Four Categories of SQL Injection

CategoryMechanism
SQL ManipulationModify WHERE clauses or use UNION to change query results
Code InjectionAppend EXECUTE commands to run arbitrary stored procedures
Function Call InjectionInject calls to database functions (mainly Oracle PL/SQL)
Buffer OverflowsExploit extended stored procedures to overflow memory

Prevention Guidance

  • Use parameterised queries / prepared statements in all database interactions — this is the primary defence.
  • Filter all input: strip single quotes, double quotes, slashes, backslashes, semicolons, NULL, and carriage returns.
  • Convert numeric values to integers before using in SQL; validate with ISNUMERIC.
  • Run the database server with a low-privilege account.
  • Delete unused stored procedures (xp_startmail, xp_sendmail, sp_makewebtask).
  • Never return detailed database error messages to users.

DMZ Protocol Attacks: Threats to Your Network’s Buffer Zone

May 13, 2026

The Demilitarised Zone (DMZ) is a semi-trusted network segment between the public internet and an organisation’s internal network, hosting web servers, FTP services, email relays, and DNS. Despite its protective design, protocols operating within it carry vulnerabilities that attackers exploit to pivot into the internal network.

DMZ Architecture Options

MethodDescription
Layered DMZSystems placed between two firewalls with different rule sets; internet traffic reaches DMZ but not internal segments
Multi-Interface FirewallSingle firewall with a third interface managing traffic between internet, DMZ, and internal network. Currently the preferred design.

Commonly Permitted DMZ Protocols

ProtocolPort(s)
FTPTCP 20, 21
SMTPTCP 25
DNSTCP/UDP 53
HTTPTCP 80
HTTPSTCP 443
SSH (management)TCP 22

Internal vs External DMZ Protocol Attacks

  • Internal attacks exploit protocols communicating between DMZ systems — e.g., compromising a web server to pivot to a database server over a trusted channel.
  • External attacks exploit protocols from the DMZ reaching into the internal corporate network — pivoting from a compromised DMZ host into the intranet.

Countermeasures

  • Apply all available patches against known DMZ protocol exploits promptly.
  • Deploy an Intrusion Prevention System (IPS) on DMZ segments.
  • Maintain a robust security policy and sound audit trail.
  • Isolate the DMZ — never connect it directly to the internal network.
  • Keep no credentials, vital resources, or sensitive internal data in the DMZ.
  • Files created in the DMZ must be reviewed by an administrator before migration to the internal network.