As the title states, wondering if there might be anyone willing to discuss enabling an SRI hash friendly implementation. I understand that this API is meant to be a dynamic resource, always using the latest version of the code, but security is of utmost importance for this application. Thanks!
Related
With Google and other services transitioning to offer full server-side operability of their marketing & analytics products, I wonder when this functionality will arrive for Optimize?
Does anyone have any insights on that or can offer a possible workaround until it's officially supported?
The stated goal is, of course, to prevent loading third-party JS and the creation of non 1st-party cookies on a users device to enhance privacy and more easily control what data is sent where.
As I understand, server-side logic is currently limited to defining which experiment and version to show. The rest of the logic, like displaying the actual version or reporting back still require optimize.js to be implemented on the frontend.
Any help is dearly appreciated! 🙏🏼
I have built a Restful Web API for my (android) mobile application, and now i am trying to secure the access to the API. I was reading for about a week on this topic and i got the whole spectrum - from those who say that is is impossible to secure a Restful API to those who say that Https (SSL) is enough.
Here I don't want to start a discussion about that.I have settled with OAuth or OAuth2 it doesn't matter(as far as I have read OAuth seems to be the better choice, but in the Microsoft tutorials they use OAuth 2, so here i am quite confused), and yes i know that they are completely different, but I am so frustrated of searching that I would accept either (I must admit that I expceted this to be much easier). As I said, I was searching for about a week, and all I got are concepts(a lot of them). You send some data -magic start - usually username/password to the server, your data is being processed and you get a token back - magic stop-. On SO there are a lot of questions on this topic but most of the answers are unprecise (and unfortunately unusuable). For example I got this one How to secure WEB API, nice answers, but not really use of them, or this one Implement Web API with OAuth and a Single Page Application. I also got the examples from the Microsoft tutorials but there is a lot of overhead in the code and the part about OAuth isn't quite clear(which is unfortunate because the whole example should be about OAuth). I could post tons of links which claim to talk about this topic, but actually they are of no help.
What I am looking for is an simple, very very simple, example of an ASP.NET OAuth(2) implementation. It would be great if I just could use it with fiddler, provide an username/password in the header and with use of grant_type: xxx I get the token back(the permitted username/password can be hard coded inside the project, so no need for Entity framework implementation or any database on the backend). And it would also be great if someone could explain me how to use this token to authorize the user (I got it that I have to provide the Controller functions with the [Authorize] attribute, but how and where is this token-check being done ?). But please, don't post any theory about OAuth, I don't need that, here I am looking for the actual implementation of OAuth inside of Asp.Net Web Api
thanks
Here is detailed post about adding the resource owner password credentials flow for your Web API project.
The most simple implementation of OAuth2 in Web API project you can find here:
WebApiOAuth2 on GitHub
There are just two important files:
Startup.cs (with settings)
AuthorizationServerProvider.cs (authorization of users using oauth2)
I'm not sure if this is the appropriate place to ask this or not, but I'm looking for a library that wraps HTTP requests in a client structure and includes the ability to retrieve and store cookies for individual sessions (like Python Requests library).
I'm looking to create a small bot for scraping a website and wanted to use it as an excuse to learn Rust.
Teepee, hyper, and rust-http don't seem to have cookie support.
However, khodzha has some in-progress work for adding cookie support to Servo. This file from his branch might be able to help you.
Warning: The code is a work in progress, I suggest you contact the author on IRC or github before using it.
I'm looking for the best reusable libraries and inbuilt features in ASP.Net to prevent the OWASP top 10 security vulnerabilities like injection, XSS, CSRF etc., and also easy to use tools for detecting these vulnerabilities for use by the testing team.
When do you think is the best time to start incorporating the security coding into the application during the development life cycle?
My two cents:
Never ever trust user input. This include forms, cookies, parameters, requests...
Keep your libraries updated. Everyday security flaws arise among us. Patches are released, but they are worthless if you don't apply them / upgrade your libraries.
Be restrictive and paranoid. If you need the user to write his name, be restrictive and let him only use [A-z] characters and so on. Strong constraints will annoy the average user, but it will make your system more secure.
Never log critical data. This means that you should not log things such as what password a user used (obvious) but also you should not be tempted to log what password did a user typed when he failed to log in into the system (because he may had a typo easy to guess). You can extend this example to all critical data. Remember, if it's not there, you don't have to worry about someone trying to get it.
And extracted from wikipedia's CSFR article:
Requiring authentication in GET and POST parameters, not only cookies;
Checking the HTTP Referer header;
Ensuring there's no crossdomain.xml file granting unintended access to
Flash movies[14]
Limiting the lifetime of authentication cookies
When processing a POST, disregard URL parameters if you know they should
come from a form
Requiring a secret, user-specific token in all form submissions and
side-effect URLs prevents CSRF; the
attacker's site can't put the right
token in its submissions
My experience is that just giving the developers a toolbox and hoping for the best doesn't actually work all that well. Security is an aspect of code quality. Security issues are bugs. Like all bugs, even developers that know better will end up writing them anyway. The only way to solve that is to have a process in place to catch the bugs.
Think about what sort of security process you need. Automated testing only? Code review? Manual black-box testing? Design document review? How will you classify security issues in your bug tracking system? How will you determine priority to fix security bugs? What sort of guarantees will you be able to give to customers?
Something that may help you get started is the OWASP ASVS verification standard, which helps you verify that your security verification process actually works: http://code.google.com/p/owasp-asvs/wiki/ASVS
First best practice: Be aware of the vulnerabilities while coding. If you code think about what your are doing.
I'm going to build an API for a web app and I'm interested in what people can suggest as good practices.
I'm already planning to make it versioned (version 1 can only control certain aspects of the system, version 2 could control more, but this may need a change in the way authentication is performed that would be incompatible with version 1), and the authentication will be distinct from the standard username/password people use to log in (if someone does use a malicious tool it won't open them up to full impersonation, just whatever the api allows).
Does anyone have further ideas, or examples of sites with particularly good APIs you have used?
Read the RESTful Web Services book, which give you a good overview of how to use REST in practice, and get to up to speed quickly enough to get started now, with some confidence. This is more useful than just looking at an existing API, because it also discusses design choices and trade-offs.
1) Bake the version number directly into the URL rather than passing it as a parameter, since that gives you complete freedom to change the organization of your API namespace with each version bump.
2) Keep your URL rewriting rules (if any) as simple/lean as possible (but no simpler), while making your URLs as beautiful as possible (but no more).
3) Always look for the best HTTP status code you can find for each response (and don't forget about 202 and 207, for example).
4) Implement fascist parameter validation logic, and informative error messages.
5) Use HTTP request headers where appropriate instead of parameters (like Accept, for example, to allow clients to specify the desired data format of the response).
6) Organize your "nouns" in such a way that the URLs used by different client audiences are separated near the "root" of your URL tree (this makes it easier to enforce different authentication mechanisms for those different audiences if needed, or even map different portions of your URL tree to different servers).
7) If you're serving regular web pages off the same domain as your APIs and use the same authentication credentials, require an X-Requested-With header in your API requests so as to avoid XSRF vulnerabiities.
I would take a look at proven APIs:
YouTube API
Twitter API
There's a lot of argument about whether these APIs are "good" but I think their success is demonstrated, and they're all easy to use.
Use REST.
RESTful web services architecture is easy to implement and uses the strengths and semantics of HTTP for what they were intended. It's resource-oriented, just like the web itself.
Amazon Web Services, Google and many others offer REST APIs to interact with their products.
Use REST.
Read up on standards for APIs, or copy the ideas from one of the popular ones.
Be careful when authenticating users.
Start very very simple.
Build a site that uses your API (even if it's not useful) to check things work. Perhaps you could build a mobile version of the site or something that forces you to use the API in a lot of depth.