14

1. Where to authenticate the user? If it is a user who needs to authenticate, then you need something in your front-end. From your front-end, you can just do a POST to your back-end, with the user credentials. You verify the user credentials, and issue an accesstoken/refreshtoken pair in case the credentials are known. You will ALWAYS have to go via the back-...


10

Mutual TLS (aka Client Authentication) is a solution to this. As for issuing certs I wouldn't do that. I would take self-signed certs from the client and pin them directly to principals (users) in some manner. I would have a lookup table indexed by both common name and certificate public key to do that. This makes potential problems like cert revocation (...


5

You should create a cryptographically random token for this. Yours is definitely not random enough, and could be guessed much quicker than the (2^122 / 2) you mention. The importance of cryptographic randomness has been discussed many times already on this forum, for example here. As you mention that you are using .net, have a look at ASP.Identity which ...


5

The MachineKey.Protect method automatically generates a random IV during encryption. You can see this in effect by protecting the same values multiple times: for (int n = 0; n < 10; n++) { byte[] data = MachineKey.Protect(Encoding.ASCII.GetBytes("This is a test."), "testing"); var sb = new StringBuilder(); for (int i = 0; i < data.Length; ...


5

Since you'll be making calls to the API server via Ajax (meaning the same page - and the same JavaScript context - will be constant) I'd suggest creating a short lived token in the main server, having the browser request it once, then using it to authenticate with the API server until the page is closed (or the token expires, whichever happens first). Next ...


5

Model Binding is quite a nice feature and may add a plus to the overall security if it is properly used. Here is how it works (the code and the features apply to ASP.NET MVC but may be the same in Ruby): Suppose you have a form in a web page: <form action="/SendData"> Email: <input type="text" name="email" id="email"><br> Address:&...


4

Request from client to server Assuming there are no vulnerabilities in the UTF-8 decoder on the server (e.g. overlong UTF-8 encoding or illegal UTF-8 continuation bytes) that could bypass a filter or other encoding routine I can't imagine any sequence that could be decoded to anything dangerous in itself. It is not like UTF-7 where a sequence such as +ADw- ...


4

It's a typical scenario with .NET MVC - search-engine friendly URLs are a direct result of proper implementation. But let's have something clear - these are not web directories, but MVC routes, right? Paranoid pen-testers are often uncomfortable when the admin interface is somehow exposed in the URL, since it can attract unwanted attention, or be harvested ...


3

From the description you have mentioned it seems that you are talking about a security vulnerability which is popularly know as Insecure Direct Object Reference. To mitigate this kind of issue, you should Check for the user whether he have access to particular resource or not. Base64 encoding the URL will not work in this. I would to recommend you to go ...


3

Running the code through a URL decoder, you can see that it is a simple Javascript and not a specific 'virus'. What you are seeing is not the actions or the result of the initial exploitation. You cannot determine the attack vector from the results. They got in through 'some means' and wrote to files on your file system. That means a code review might not ...


3

There is no configuration available, as far as I'm aware, that can limit the user to a single session id. No, you'd have to do it yourself. Not sure how your auth-and-session model is working at the moment, but in general the approach would be to keep a persistent lookup table of user IDs to their session ID, and moan when there's a mismatch. Is this ...


3

For standard applications I usually raise this as a "low" priority finding, mainly as if an attacker has compromised an account, it can be a useful restriction to have a user only able to maintain a single session and log out old sessions when a new one is started, that way the attacker gets kicked out the next time the user logs in. In this scenario the ...


3

Without seeing the code it's impossible to say for sure what is going on. Based on my own experience I suspect the following is what is happening. Lets say you have a vulnerable piece of code that defines a query to be executed in the db like follows: string commandText = "SELECT id from users where name = '" + tb_Name.text + "'; If you then pass in your ...


3

Use a cryptographically safe cookie value such that modification of the value would invalidate the session. In other words cookie = encrypt(username, expiration, secret) Where only your application knows the secret. With that said, don't do this yourself. There are a ton of ways this can be done securely in MVC.


3

ASP.NET MVC uses a variation of synchronizer token pattern. In a typical implementation, syncrhonizer token pattern works by generating a large random token and preserving it in two locations: Session state (either on server or client) In a hidden form field When a form is submitted, server will check that both values match and fail if they don't. This ...


2

Don't trust the URL... since POSTed data may hide what is really going on. The URL should be treated as a client-side value and should not be trusted anyway. Anyone can easily alter the URL and could easily create a POST to any UserID. Anyone who can guess the route variable names in ASP.NET MVC, can put unexpected data into a controller This can happen ...


2

I thought the AFT in the cookie and the one in the form were supposed to match. You were wrong! they doesn't need to be equal - However, they have some cryptographic relations with each other... Here you can find detailed info about this feature and how it works...


2

is there a way to see what company an ip address is assigned to? You can find additional information about an IP address by using WHOIS services. ARIN, is a good start, and will redirect you to other registries (such as LACNIC or RIPE) when needed. For most activity from legit search engine bots, the WHOIS will also contain the name of the company. For ...


2

(SilverlightFox's answer is great. Consider my response below a related note rather than an answer in its own right.) MSDN warns against running untrusted input through the UTF7Encoding class. Recent versions of ASP.NET have actually dropped support for UTF-7 since no legitimate client will send data to a web server using this encoding. In these scenarios,...


2

You could include not only code, but also user identifier in the password reset link. For example: www.example.com/account/forgot-password?user-id=a45sdf48kf345&token=TOKEN Whenever someone visited the Forgot Password link, you would validate not only token and its expiration date but also user id before resetting password. In this scheme attacker ...


2

No, these headers don't say anything about the server itself, only that it's running Windows (Because of the IIS). The other two headers are the .Net and MVC framework version, which both are respective to the application running in the IIS. You can find more information about those headers and how to remove them here.


2

Yup, it's fine. Underneath the covers it users the RNGCryptoServiceProvider to generate the password data, which is .NET's wrapper around the CryptoAPI's CSPRNG to generate the data for the password. It's good enough for strongly random key material, so its certainly also good enough for a one-time use password as well.


2

There's one pretty major issue that's immediately apparent, but may be an artifact of your development environment: the request is transmitted over plain ol' http, which means the API key is available to anyone performing a man-in-the-middle attack. The solution for this, of course, is to only ever make these sorts of requests over https. You can't control ...


2

The issue that they're referring to is sensitive cookie exposure, in particular, cookies that contain an authentication or session token. In this case specifically, you should never force an authenticated user to HTTP, and allow them to remain authenticated. This used to be a common practice, even among very large web properties until a tool called ...


2

I am experiencing an issue with certain emails coming from exterior services such as yahoo, and google. Specifically that requested resources can only be accessed via SSL. Okay, so you receive an email, and it contains links to encrypted (https://) content. there are potential issues with reversing the operations of a forced HTTPS operation to ...


2

If the CSRF token can be intercepted then the session cookie can usually be intercepted as well, so CSRF wouldn't be the immediate concern in that scenario. Some CSRF token implementations have timed expirations, but this is an extra precaution and not strictly necessary. This answer from tylerl suggests that an expiration is a good precaution in case the ...


2

We've had this discussion with many clients over the years. The most valid solution for CSRF protection is one where the server tracks what 'page' was sent to the client, then only accepts valid data from the page that was served, from only the client it was served to. It's been a while since I've been on the programing side with MS, but the @...


2

The only security issue I can see with this is that you will have your usernames appear in all sorts of logs and in your users browser history. For most applications, that wouldn't really be a problem though. Also, you might want to opt out from sending referer headers from the login page. Otherwise, if you link to external sites you could leak usernames to ...


2

Visiting a URL can cause a side effect. For instance, if I'm logged into Amazon, visiting a URL may cause an item to be purchased and shipped to me (one-click buy). That's a side effect. Or, it might log me out, or log me in, or update some settings. Those are side effects, too. In general, a operation has a side effect if it changes some (persistent) ...


1

Disclosure of ASP.NET Server errors is primarily an information disclosure issue When this happens you are disclosing information about the technology in use. If it's just the default errors (not the verbose ones) this is pretty limited, if it's the verbose one's you're disclosing stack traces and detailed ASP.NET version numbers. The impact of this ...


Only top voted, non community-wiki answers of a minimum length are eligible