Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I write a phrase and please you say your point of view about it:
For my web site,If My Server Is Secure(Server Admin warranty that) and I prevent XSS and Sql Injenction attack,Is my web site secure?
(please leave your answer with reference)
Thanks
Edit 1 ::
every of above items + Cross-site request forgery
Firstly, don't expect to obtain a "secure" end state as if it's an absolute position - you can't. Software security is about reducing risk and you won't ever reach a position of no risk.
There are many, many other risks you've missed: broken authentication and session management, insecure direct object references, security misconfiguration, insecure cryptographic storage, failure to restrict URL access, insufficient transport layer protection and unvalidated redirects and forwards to name a few. These are all out of the OWASP Top 10 and I suggest you start with these.
Make sure you understand:
The risk
How it's exploited
How you can protect against it
If you'd like to see all this in the context of ASP.NET have a read through the OWASP Top 10 for .NET developers series.
And thee are risks beyond these top 10 too, they're just the most common ones in web apps.
No. There are other attack methods. For example, http://en.wikipedia.org/wiki/Cross-site_request_forgery
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 4 months ago.
Improve this question
So, I am trying to safely store an authentication token using Angular, processed with additional encryption on top (in front end) and put it in browser local storage (so that not anyone can de-code it).
Many people recommend this method, but I came across several opinions that say even in such case one can access your source code through your browser and get your secret key to decrypt the Auth Token (for example experienced hacker).
Many people claim that Access + Refresh tokens are the best in terms of security.
So, my question is - what are standard practices for serving/ storing authentication token? Is token encryption in local storage good implementation or should we use refresh tokens (although, they are harder to implement)?
I think you should use both a refresh and access token for maximum security...the access token should have an expiration date and should be blacklisted after rotation(when you use the refresh token to get an access token)...if you need even more security,after rotation,the user should get a new refresh and access token
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
Is it possible to send content over the network to client without client being able to extract the content to their local machine?
I mean what if someone decides to sell media content using browsers, then once someone gets hold of the content he or she is able to go to Chrome Inspect - Network and just download the content to their local machine, which would enable them to spread the content for free later on (while initially the access to the content was provided just for someone who is authenticated for the site serving the content and paid for the content).
Are there any headers maybe which would prohibit doing so?
You're asking how to do effective DRM, which is well-known to be impossible. Think about it from this perspective: if what you're describing were possible, Hollywood would do it and there'd be no such thing as movie piracy.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We should log post data or not, if not then why?
I did not get proper answer anywhere.
It is best not to log any events containing personally identifying information (PII) or security credentials, as that makes your log storage system a greater privacy and security liability than is strictly necessary.
For this reason, people frequently avoid logging the body of POST requests, as they might contain user's email addresses, passwords, user or internal API keys, etc.
However, you may safely collect such logs if you write application-specific rules to sanitize these log messages of sensitive information.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I know this may be not a good question.
I was asked a question: do we really need authentication among microservices. And I have no idea the answer. I did read some tutorials on SOA, microservices, and how to add authentication among the services. But I did not have too many ideas why we need authentication/authorization between microservices? Any use cases where they are required? Any use cases where they are not required? Any potential risk without authentication/authorization?
Any comments welcomed. It is better to give some practical examples. Thanks
Whether a microservice that you design and develop requires authentication is up to your functional requirements and the way you design it.
A common technique used is to not have authentication on each individual microservice but to group them together behind a common fascade (such as an API Manager). You can then apply authentication and other policies at one place - the policy enforcement point/API Manager - for "external" consumers while "internally", behind your common security boundary, your microservices remain lightweight and can call each other without authentication (if that makes sense for your usecase/requirements/architecture etc. etc.)
To sum up - it's a design decision that involves multiple tradeoffs.
Clearly, if you have a critical business service fetching or updating sensitive data, you might want only authorised callers to access it. But you might not want many internal callers (could be other microservices) running within your organisation's "trusted" network to be burdened with unnecessary policy enforcement.
But then, there might be situations where even internal callers need to authenticate properly (e.g. if it is a payment service)
Authentication/authorization in most cases is needed for microservices that provide public API, as they are available/visible for the World.
Why? Cause when someone from the World calls the API method, we (in most cases) want to know who the client is (do Authentication) and decide what client is allowed to do (do Authorization).
On the other hand, for internal microservices (in most cases) the client's are well-known as they are other internal microservices. So until you don't need to provide different restrictions of use for different internal microservices there is no need for authorization. Note that I assume that internal components only available within the organization.
If your organization is considered with internal threats (and why wouldn't they be?), then yes all microservices need to be protected from malicious use.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
What would be a good way to restrict an ASP.NET web application to only serve a given ammount of concurrent users?
Some requirements are:
Application requires login (no need to worry about anonymous users).
Multiple servers support (farm / load balancing).
An active user can be considered to be the same as an active session (not signed off or expired).
Additional logins must be denied if the maximum number of concurrent users has been reached.
Accountability is needed (administrators should be able to see who the active users are).
Minimum overhead on each web request (especially avoiding costly trips to a database on each request).
Total number of concurrent users should be kept correct even if a web server hangs, disconnects from network or has to be restarted.
Additional servers are available to host services (e.g. application servers).
You could use a global variable (static) and hook up the logic in your Application_OnStart, Application_BeginRequest, or Page_Load events. Check out this for more an example: http://dotnetperls.com/global-variables-aspnet
To restrict the number of concurrent users you should be able to use,
<system.web>
<applicationPool maxConcurrentRequestsPerCPU="12" maxConcurrentThreadsPerCPU="0" requestQueueLimit="5000"/>
</system.web>
http://blogs.msdn.com/b/rakkimk/archive/2009/07/08/iis7-improving-asp-net-performance-concurrent-requests-while-on-integrated-mode.aspx