Whenever any application(browser, thick client application) is requesting to generate an AES key, I would like to supply a static key to that application.
Is there any way to do this in Linux or windows?
There is not an universal way of generating AES keys that applications needs to adhere to.
Forcing a static key on an arbitrary application ought to be hard/impossible if the application is secure - and would be a case by case activity.
Related
I managed to to POST/UPDATE and DEL request from React application (from different microfrontend using Webpack 5), to multiple backend application (microservice) written in Node JS.
Each data is encrypted using a key created with symmetric key. The symmetric key is also encrypted using Public key from client. Then both encrypted data and key sent to server to be decrypted in the server for storing.
What about GET request ? How do I do reverse encryption of data sent from server to be read on the client, especially I have multiple micro front end client. Do I create multiple RSA pair keys for each micro front end, with private keys stored in each client, public key to be sent along with GET request to the server ?
I would like to ship my app to my client with my own public key. This key will be used when my clients need to export IP data from my app for debugging purposes. This data needs to only be readable by myself. Suppose that clients can not read my code and can not access my app's memory but would be able to identify my public key inside the app and maybe replace it with theirs thus making the exports readable by them. What options do I have to ensure that my public key is actually a pair for my own private key before commencing the export?
If we assume the OP's threat model, specifically that the attacker is not debugging the app and/or somehow messing with the process' memory in run time, the app should validate the public key before performing encryption, wherever the public key might come from.
In the order of diminishing strength:
digital signature from a public certificate authority (it will be paid), rely on system trusted roots
digital signature with another private key that the OP possesses (hard-code the public key in the app)
HMAC of a public key with a hard-coded secret
hash of a public key
In case of RSA keys, the modulus pretty much identifies the public key. The public exponent in most vendor implementations of RSA that I'm familiar with is hard-coded to 65537 anyway.
I work on an app that is scanned by the Burp tool before the code is released to production. The recent scan has resulted in OS Injection attack vulnerabilities.
In doing research the only examples of OS injection attacks I saw were for unix, java, php apps.
Are these attacks possible against an ASP.NET (MVC) application? If so, how do you mitigate this risk? Does ASP.NET (and/or MVC) itself prevent OS Injection attacks?
The framework is not vulnerable to OS injection attacks itself. It is the code that you write with this framework that can be vulnerable. For example if you have a controller action that executes a command that is passed as parameter from the outside your application immediately becomes vulnerable. Consider this example:
public ActionResult Index(string fileName, string arguments)
{
Process.Start(fileName, arguments).WaitForExit();
return View();
}
So basically no matter what framework or programming language you are using for developing your application you should never trust user input and perform proper sanitation before accepting it.
OS Injection is defined by the OWASP Foundation as follows:
Operating system commands Calling external applications from your application.
[...]
What we should be looking for are relationships between the application and the operating system. The application utilising functions of the underlying operating system.
In java using the Runtime object, java.lang.Runtime does this. In .NET calls such as System.Diagnostics.Process.Start are used to call underlying OS functions. In PHP we may look for calls such as exec() or passthru().
But of course your research already showed that.
Are these attacks possible against an ASP.NET/MVC application?
So, yes, anywhere you use, or any library you use uses System.Diagnostics.Process.Start(), either directly or indirectly supplied with user input, you're at risk.
If so, how do you mitigate this risk?
As usual, by properly escaping and sanitizing user input where necessary. This includes not only query string or route parameters, but also cookies, HTTP headers and whatnot.
I am currently building an ASP.NET Web API which unique purpose is to provide data to a Windows Phone app. I already finished the Web API development and I published it in an Azure website for testing purpose.
It works like a charm but my issue now is that this Web API is now publicly accessible. What I would like is to find the simplest way to limit the audience to my particular Windows Phone app and nobody else. I first thought of using an API key but it does not seem that ASP.NET proposes this as a builtin option. The builtin options are not satisfying either because their require a login.
Basically I want that only my Windows Phone app can access the Web API and that this authorization is transparent for the user (no authentication required). Any suggestions?
PS: The Web API is deployed on Azure, will not be distributed to other developers and securing with HTTPS is a possibility.
I did an implementation and blogged about it : http://www.ucodia.fr/blog/simple-authorization-asp-net-web-api/
As you're looking for a very basic, stop the casual hacker method, there is a simple technique that can be used with the Web API and ActionFilterAttributes. As there are two identically named attribute classes with that name, make sure you're using the one from System.Web.Http.Filters.
It would be very common to send a token of some sort, that would either be generated, or encoded permanently into the application. So, in this example, a header value would be encoded into every request, and then checked using the filter.
[VerifyToken]
public class MyAPI : ApiController
{
}
public class VerifyTokenAttribute : ActionFilterAttribute
{
public override void OnActionExecuting(HttpActionContext filterContext)
{
// get the token from wherever you'd like ...
var token = filterContext.Request.Headers.GetValues("Token").First();
if (token != GetCurrentToken())
{
filterContext.Response =
new HttpResponseMessage(HttpStatusCode.Unauthorized);
}
base.OnActionExecuting(filterContext);
}
}
Does it need to be truly secure? or just secure enough?
For 'secure enough', I will usually just use an API key as you suggest that the client app passes to the back-end and for which the back-end will not respond if the key doesn't match. This will provide a very basic level of security to prevent someone who just happens along from executing arbitrary api calls; for read only, non-confidential data this has usually been enough for me.
For a bit of added level of security you could you a rotating time-sensitive api key that changes based on the time of the day (with perhaps a sliding window to account for minor clock differences between clients and server). This ups the security by obscurity just a bit more, requiring someone to do a bit more work before they crack your code.
Depending on your app, it might also be a good idea to consider rate throttling your API responses as well, if there is a discernible max number of calls any given client should make to your API, you could geometrically slow down the responses to thwart attempts at misuse if someone does bypass your security.
Is it possible to store encrypted connection string so it can be used from server-side vbscript?
Was there an equivalent of web.config in 'the good old days'?
As I dust off the ol' memory banks...
I recall that in classic ASP systems, we would put the connection string (and most other config settings) in the Windows registry, in a custom registry key for the web app. We'd use a COM DLL to read the settings.
You can encrypt the connection string that is stored in the registry, but you will have to roll your own encryption/decryption.
So the answer is yes, it is definitely possible, but there is no easy tooling built into the framework to encrypt/decrypt on the fly, you have to do it yourself.
.Net has all the encryption and decryption code built in so the easiest way to encrypt the string is to use the .Net encryption/decryption functions. Create a .Net component that does the decription and a COM callable wrapper for it which should register it. Then call it from your ASP page.