In today’s interconnected world, Application Programming Interfaces (APIs) have become the backbone of modern software development. They enable seamless communication and interaction between different systems and applications. However, this convenience comes with inherent security risks. To mitigate these risks and ensure the integrity of the entire system, integrating API security into the DevSecOps framework is essential. In this blog post, we will explore the best practices for API security within the context of DevSecOps, focusing on British English conventions.
Continue reading Ensuring API Security in DevSecOps: Best Practices for a Robust SystemCategory Archives: Security
WebSocket Security Issues
Places I have been working they have banded the use of WebSockets to pushing data to the end-user, or devices. I want to delve into the concept of WebSocket introduced in HTML 5, security issues around the WebSocket model, and the best practices that should be adopted to address security issues around WebSocket.
Continue reading WebSocket Security Issues
Cross-Site Request Forgery (CSRF)
Description
It is possible to trick a user into executing potentially dangerous actions against the target site due to a lack of Cross- Site-Request-Forgery (CSRF) protections. CSRF attacks are a class of confused deputy attacks that exploit the behaviour of browsers always sending authorization cookies in requests. The target site has no secure way of verifying the request was initiated from a link on a trusted domain.
Improper Certificate Validation
Description
The SSL Certificate Details provide information about the certificate associated with the HTTPS server. This information describes important attributes of the certificate and should be reviewed for the correctness of the contact information, whether it is self-signed, and how soon it will expire. The Supported Ciphers provides information about each available encryption scheme available for each of the possible SSL/TLS protocols.
Recommendations
The expiration date for certificates should be monitored. New certificates should be available before the expiration date in order to maintain continuity of service and avoid downtime or displaying certificate expiration errors in users’ web browsers.
Server-Side Request Forgery (SSRF)
Description
“Server Side Request Forgery” (a.k.a. SSRF) is a class of web-application vulnerability in which an attacker can cause a website to access unintended server-side resources, including the unauthorized reading, writing, or execution of server resources.
Web-applications designed to pass URLs (references to server accessible content) or portions thereof, from the client browser to the application server using HTTP request parameters or HTTP request headers, are at risk for Server Side Request Forgery exploitation unless they protect against it.
Server-side Request Forgery (SSRF) is related to another type of vulnerability called Open Redirects in the sense that they both rely on untrusted input to reference other web-resources.
Strategies for avoiding and/or fixing Server-Side Request Forgery include:
- Design around it: Unless there is a reason why URL information must be passed, avoid the problem entirely by implementing an alternative design.
- Validation: When a URL value is received by the application, it must be white-list validated against the domain of possible legitimate values and rejected if it is not a member.
- Indirect References: In some cases, it may be possible to pass a (cryptographically strong) random value that represents the target URL and maintain a token: URL mapping on the server. Since URLs are never passed and the tokens are (practically) un-guessable, the vulnerability is eliminated.
If URI is hard-coded, then the attacker cannot influence where the request is going, so it would look to be a false positive. However, although some scanning software is known for false positives, you need to be careful, as most scanning software are correct in their analysis. You need to check the whole source-to-sink trace that scanning software provides? If it is reporting only that one line as the source and sink, then yes it is a false positive.
Useful links:
https://www.owasp.org/index.php/Server_Side_Request_Forgery
Improper Neutralization of CRLF Sequences in HTTP Headers
Description
A function call contains an HTTP response splitting flaw. Writing untrusted input into an HTTP header allows an attacker to manipulate the HTTP response rendered by the browser, leading to cache poisoning and cross-site scripting attacks.
Recommendations
Remove unexpected carriage returns and line feeds from untrusted data used to construct an HTTP response. Always validate untrusted input to ensure that it conforms to the expected format, using centralized data validation routines when possible.
A simple string extension can resolve this issue:
public static string CRLFRemoval(this string token) { return token.Replace("%0d", string.Empty, StringComparison.InvariantCultureIgnoreCase) .Replace("%0D", string.Empty, StringComparison.InvariantCultureIgnoreCase) .Replace("\r", string.Empty) .Replace("\n", string.Empty) .Replace("%0a", string.Empty, StringComparison.InvariantCultureIgnoreCase) .Replace("%0A", string.Empty, StringComparison.InvariantCultureIgnoreCase); }
Links for reference:
https://en.wikipedia.org/wiki/HTTP_response_splitting
https://securiteam.com/securityreviews/5WP0E2KFGK
https://www.owasp.org/index.php?title=Testing_for_HTTP_Splitting/Smuggling_(OTG-INPVAL-017)
Symmetric encryption/decryption routine using AES
The following is a symmetric encryption/decryption routine using AES in GCM mode. This code operates in the application layer and is meant to receive user-specific and confidential information and encrypt it, after which it is stored in a separate database server. It also is called upon to decrypt encrypted information from the database.
The full description of the AES in GCM mode can be found in this document produced by David A. McGrew and John Viega The Galois/Counter Mode of Operation (GCM)
Azure Key Vault
This is how, within your organisation, you can protect the data, especially in a cloud-first, multi-tenant world. The source will provide you with the concepts around encrypting enterprise data, look at what you should encrypt, and cover robust patterns and practices you can follow in your organisation.
Enjoy.
Security Links and References
To get a level of how many data breaches are happening Breach Level Index provides this information, along with many other statistics
Need to check if you have an email account that has been compromised in a data breach when check out Have I Been Pwned to check if you have been compromised and also Signup to get email notifications
For a collection of Cryptography APIs in one library
HSM hardware
Allow access to Azure services, what does this actually mean?
I did some quick research on the SQL Server Firewall “Allow Access to Azure Services” option in Azure today.
And I sorry to say that my fears were right, that by setting this option does pose a significant security risk and leaves the SQL Server vulnerable.
Here is the extract of the article I found from Gaurav Hind at Microsoft
Access within Azure: This can be toggled by “Allow access to Azure services” Yes/No button on the portal (Firewall settings page). Please note, enabling this feature would allow any traffic from resources/services hosted in Azure (not just your Azure subscription) to access the database.
The big question now is how do you plug this gap in the firewall? One possible solution is to build a virtual network within Azure or Filter network traffic with network security groups, this is beyond the scope of this article.