As you may well know, it is required to host an access policy
(clientaccesspolicy.xml) on your web server if you want SL apps
to perform HTTP requests, or you need to host an access server
on port 943 for socket connections.
My app makes many short requests and latency is important. I want
to know if this access policy file is accessed once for every
new HTTP request or is it accessed for the first request and have
its result cached on the client. It would be quite costly for me
to have two web requests (one for the policy, one for the HTTP GET)
for each HTTP request I create.
One easy way to test this is to use Fiddler and watch for requests to the policy file. The documentation also specifies that the cross-domain policy file is requested only once per application session. This means that the runtime will only request it once and store the result in memory for the silverlight session.
Related
I'm really struggling to wrap my head around the concept of protecting ones API end point.
How do you do you protect it from abuse if it's exposed with React?
I understand if a user were to login then be issued them with a token etc. I get that. But let's say have a front end that does not require someone to be logged in?
They simply filling out a form with their details and it gets passed via you API then gets stored in the DB.
Whats stopping someone just abusing your API? They could just write a script and attack you end point with spammy data?
I just can't understand how this is protected?
you can set CORS headers, allowed hosts and also rate limiter for protecting your APIs in Django.
Allowed hosts: A list of strings representing the host/domain names that Django site can serve. This is a security measure to prevent HTTP Host header attacks, which are possible even under many seemingly-safe web server configurations.
CORS headers: Cross-Origin Resource Sharing (CORS) is an HTTP-header based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading resources. It's used for working with browser clients.
Rate limiting: A rate limit is the maximum number of calls you want to allow in a particular time interval. For example each unauthenticated user can only do 100 requests per minute.
And also if you are deploying your app in a PaaS service then you can deploy your django app as an internal service and your react app as an external service. Then Django is not only usable inside the containers not outside them.
I am currently designing a web application using AngularJS. In this I am fetching and posting data via Rest API(s) with different methods. The data I retrieving is fetched in the form of JSON.
Problem:
Issue here is, while I am using https, the data sent and received via HTTP requests can still be seen in proxy tool or traffic monitors. All the JSON can be easily read from this.
Each of my request has a token attached in it's header which takes care of authentication. However, once authorized, there is some part I don't want to be displayed in/ caught in such monitoring tools.
Question:
This data is stored in an encrypted way in database and all, however while coming via HTTP request, it is first decrypted and then sent. How can I hide/protect this data?
You can't.
If you give it to the client, then the client has to be able to see it.
If the user has configured their browser to proxy requests, then the proxy is the client.
Once the data leaves your server in an HTTP response then anyone/anything thing the user of the client wants to trust with that data can access it. You don't have control at that point.
proxy tool or traffic monitors will see https data only if the client has accepted the man-in-the-middle (MITM) by installing the ssl certificate used by the MITM:
To see the content (other than the host name) of an https connection, someone who is neither the client or the server must do a MITM.
If someone do a MITM with a certificate not trusted by the client, the client will reject the connection.
WARNING: If the server do NOT use HSTS, the person doing the MITM can do an SSLSTRIP attack if the first connection is http. In that case, the MITM do not need a trusted certificate because the connection will stay in plain text (http)
I'm building an AngularJS application that will interact with RESTful services running on a different host. Since requests are going across origins, CORS is getting into the picture. Since requests specify JSON as expected content type, CORS preflight requests are triggered by the browser. Straightforward so far.
According to W3 spec, CORS preflight requests should exclude user credentials. The RESTful web services application is protected by SiteMinder, which is configured to enforce authentication based on URL. Web services depend on SiteMinder for authentication and handle authorization only. That's why SiteMinder cannot be removed. As a result, CORS preflight requests come back with HTTP 401 Authorization Required. It prevents browser from moving forward with the actual request.
Any ideas about how to enable CORS preflight requests in a SiteMinder protected environment? Thanks a lot in advance!
You can try to ignore OPTIONS method by setting autoauthorizeoptions = yes in ACO parameters for the agent
++++++++++++++++++++++++++++
Allow Automatic Access to Resources that use the OPTIONS Method The SiteMinder Web Agent still challenges authenticated users who attempt to access resources that use the OPTIONS method. Some examples of resources that use the OPTIONS method include (but are not necessarily limited to) the following:
Microsoft® Word documents
Microsoft® Excel® spreadsheet documents This challenge occurs because the application associated with the resource sends a request using the OPTIONS method to the web server. Because this request does not include a SiteMinder cookie, the Web Agent issues a challenge.
To prevent users from being challenged for these resources
Set the value of the following parameter to yes:
autoauthorizeoptions
Automatically authorizes any requests for resources which use the HTTP OPTIONS method.
If you set the value of this parameter to yes, also set the value of the PersistentCookies parameter to no.
Limits: yes, no
Set the value of the PersistentCookies parameter to no.
++++++++++++++++++++++++
The silverlight enabled WCF Service communication is secured using a USB token/smartcard. The first access has to be confirmed by entering a PIN. Once authenticated, a malicious website could start CSRF requests to the WCF service using IMG-Tags and/or JavaScript. According to the Security Guidance for Writing and
Deploying Silverlight Applications, a usual technique here is to use (session-)tokens or a so called "nonce", while checking the HTTP Referrer header has proven to be insecure.
I understand the idea behind this, to my understanding it works well if you have a single form (i.e. contact form) and a single service where you can ensure that a user has to see and fill out the form before sending. In a Silverlight application, I'm not able to predefine such kind of sequence, many requests (like requesting a price update for a product) can be started in an arbitrary order.
Do you have some advices how I should secure the Silverlight to WCF communication to prevent CSRF attacks, ensuring that an already authenticated caller requests from a trusted site?
One option could be:
Provide a service that when called, created a nonce and stores it on the users session on the server, and returns it to the calling application
On every request after this one, include the nonce as a URL parameter or in the POSTed body of the request (or within any other type of message you use)
Check for this nonce for every request to the server
An attacker could not trick this, because if he called the mentioned service he would get a different token for their own session. And as long as this nonce is not stored in a cookie, it will not be automatically submitted by the browser upon requests to the server. So as long as the attacker cannot guess the nonce (use a cryptographically secure random to generate it), this should work.
I'd like to use the URL fetch service for app engine (java). I'm just sending a POST to one of my own servers from a servlet.
AppEngine -> post-to: https://www.myotherserver.com/scripts/log.php
I'm reading the url fetch doc:
Secure Connections and HTTPS
An app can fetch a URL with the HTTPS method to connect to secure servers. Request and response data are transmitted over the network in encrypted form.
The proxy the URL Fetch service uses cannot authenticate the host it is contacting. Because there is no certificate trust chain, the proxy accepts all certificates, including self-signed certificates. The proxy server cannot detect "man in the middle" attacks between App Engine and the remote host when using HTTPS.
I don't understand - the first paragraph makesit sound like everything that goes from the servlet on app engine, to my php script is going to be secure if I use https. The second paragraph makes it sound like the opposite, that it won't actually be secure. Which is it?
Thanks
There are two things HTTPS does for you. One is to encrypt your data so that as it travels over the internet, through various routers and switches, no one can peek at it. The second thing HTTPS does is authenticate that you are actually talking to a certain server. This is the part App Engine can't do. If you were trying to connect to www.myotherserver.com, it is possible that some bad guy named bob could intercept your connection, and pretend to be www.myotherserver.com. Everything you sent to bob would be encrypted on it's way to bob, but bob himself would be able to get the unencrypted data.
In your case, it sounds like you control both the sending server and the destination server, so you could encrypt your data with a shared secret to protect against this possibility.
The UrlFetch through https has been fixed allowing certificate server validation.
validate_certificate
A value of True instructs the application to send a request to the
server only if the certificate is
valid and signed by a trusted CA, and
also includes a hostname that matches
the certificate. A value of False
instructs the application to perform
no certificate validation. A value of
None defaults to the underlying
implementation of URL Fetch. The
underlying implementation currently
defaults to False, but will default to
True in the near future.