(Avoid shared databases). When multiple services consume a shared data schema, it can create tight coupling at the data layer. To avoid tight coupling, each service should have its data access logic and separate data store. The development team is free to pick the data persistence method which best fit each service and nature of data.
Continue reading Decentralised Data ManagementAll posts by bryan
Microservices Best Practices
API Gateway
API Gateway acts as a single entry point for all clients with a more critical role as an edge service for exposing microservices to the outside world as managed APIs. It sounds like a reverse proxy, but also has additional responsibilities like simple load-balancing, authentication & authorization, failure handling, auditing, protocol translations, and routing. There are several ways in which the API Gateway can be deployed from a development perspective.
Continue reading Microservices Best Practices
Microservices
Microservices is a trending topic among software engineers today, why is this? In this post, I’ll endeavour to take the mystery and explain things in plain English so you can build genuinely modular, business agile IT systems with Microservices architectural style.
The goal of microservices is to increase the velocity of application releases, by decomposing the application into small autonomous services that can be deployed independently.
Continue reading Microservices
Docker – Basic Concepts, Components and Advantages
Docker’s containers allow for the immense economy of scale and have made development scalable, while at the same time keeping the process user-friendly.
Let’s get to work and see what it is all about, we’ll go over the following:
Continue reading Docker – Basic Concepts, Components and Advantages
Docker Containers
What is Docker? It is a hot topic in cloud computing, one that people are finding ample job opportunities with skills in it. But what is Docker used for?
Continue reading Docker Containers
High-performance JSON API
Raw System.Text.Json
.NET Core 3.0, has shipped with the new System.Text.Json APIs, which provides built-in support for JSON, including reader/writer, read-only DOM, and serializer/deserializer. With the performance, the main improvement to the methods, check and see the typical speedups of up to 2x over Json.NET.
Async Streams
The new feature Async Streams in C# has removed the scalar result limitation and allows the async method to returns multiple results.
This change makes the async pattern more flexible so that you can retrieve data in lazy asynchronous sequence from a database or you can download data from an asynchronous sequence that returns the data in chunks when they become available.
Continue reading Async Streams
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