I've got a web application that's running Js on client side and c# on server side - What would be the best way for them to communicate over the internet and how would I pull that off - would really appreciate some resources, I've been looking around for a bit now and couldn't find anything.
There wont only be credentials from forms that will be passed through, there will be other data coming from the server time to time as well
The best answer is WebSocket. I believe that there is good support for this in c#, and I know for myself that it's pretty easy to set up in JavaScript. You can use "ws" or a secure connection with "wss".
The one thing I would warn you about is with "credentials" and sensitive information in JavaScript. On the client side, you basically have no control over preventing sensitive information from leaking. Web pages can be altered and inspected by the client. So be careful about what your server sends to your client.
Related
We are creating an online service divided like that:
- an API, of course
- full JS/AJAX client, no MVC, it is pure JS
We are experienced developers and we do know that we can't secure the JS client code, however, we are trying to figure way to prevent 3rd parties from creating their own client by analyzing our JS API Call and this way restrict access only from our own client.
Thanks in advance!
We are experienced developers and we do know that we can't secure the
JS client code, however, we are trying to figure way to prevent 3rd
parties from creating their own client by analyzing our JS API Call
and this way only restreint access from our own client.
That is contradiction in terms. If you know that client-side ECMAscript code can never be hidden, it will always be possible for any somewhat experienced developer to analyse your code. Even if heavily obfuscated, minified and uglified.
Use a server-side authentication, by password. Its the only secure way. You just can not prevent that somebody will clone/copy your script.
I don't think you can. Perhaps generate a key or something to authorize requests.
For you and anyone with a similar question, take heed; it is impossible. If you send a user working code that will communicate with your API, there is nothing you can do to stop then modifying or re-writing that code. The only area you can keep secure is the back-end.
Oh, this is the wrong question to ask.
The question you need to ask is "why do I care if someone accesses my server without my client?"
You obviously have a reason. I can think of one reason only - your server trusts the client to behave nicely. Don't do that. Make sure the server can handle any kind of zany client request. It doesn't have to handle it nicely (throwing a 500 Server Error is OK) - as long as rogue clients can't mess with your data or kill your server entirely.
You could try to obfuscate your javascript code to make it hard readable:
a link to an obfuscator
you can find outhers
If you have authentification, you can pass session id to your API to keep user logged in, so if user is not authentificated he won't be able to get data from your API.
I'm working on a school project for that I've to make a forum. So I want to make it light using javascript which is run on client side. So regarding this I want to know how can I use sqlserver with javascript on asp.net. I'm new commerce and don't know much about this. I know how to handle it with c# but as every one knows it makes heavy due to run on server side.
You'll need some kind of server-side piece. You can't use JavaScript on the client to talk directly to an SQL Server instance. Even if you could hook it up in terms of the protocol and port and such, A) You'd have problems with security policies, and B) It would be a Really, Really Bad Idea to allow clients direct access to the DB.
So the typical architecture is: Client -> mid-tier -> database
These days it's not atypical for the mid-tier to be some kind of web service exposing a REST, XML, or JSON API.
You have lots and lots of choices for the mid-tier. Certainly C# and ASP.Net is one choice, but only one. There's Ruby on Rails, there's any number of JVM-based frameworks (Java EE, Play!, ...), there's PHP, there's Node.js...
I suppose one choice for the mid-tier is SQL Server itself. SQL Server 2005 offers a built-in set of web services you can enable via SOAP/HTTP. You would probably still run into issues with the Same Origin Policy, since I assume you won't be serving your web pages from the SQL Server. :-) Or maybe you could get around that, by configuring IIS to proxy for the SQL Server's SOAP/HTTP stuff and also to serve your pages, so they'd all be on the same origin (the host and port of the IIS server).
I am researching how to PunchOut enable a webstore and from what I read, I have to use a server side language. Unfortunatly I am limited to only using Javascript. Can this be done? Does anyone have any best practices or can point me to a reference for enabling a PunchOut ecommerce store by only using Javascript?
According to the cXML Users Guide (http://xml.cxml.org/current/cXMLUsersGuide.pdf) on page 23 it states "PunchOut catalogs are made possible by Web server
applications, written in a programming language such as ASP (Active Server Pages),
JavaScript, or CGI (Common Gateway Interface), that manage buyers’ PunchOut
sessions.". Based on that it sounds possible as they call out JavaScript, but they also call out the fact that it is done by Web server applications. I have not used a strictly JavaScript myself, just ASP and recently .NET.
However, I'm not a JavaScript expert so YMMV. The main thing to keep in mind that most punch-outs (especially from Ariba) will be initiated via an HTTP POST with the cXML document XML as a form value. If you can use JavaScript to process that XML and send back a response without server side work, then you should be good to go.
In a previous question I asked about weaknesses in my own security layer concept... It relies on JavaScript cryptography functions and thanks to the answers now the striking point is clear that everything that is done in Javascript can be manipulated and can not be trusted...
The problem now is - I still need to use those, even if I rely on SSL for transmission...
So I want to ask - is there a way that the server can check that the site is using the "correct" javascript from the server?
Anything that comes to my mind (like hashing etc.) can be obviously faked... and the server doesn't seem to have any possibility to know whats going on at the clients side after it sent it some data, expept by HTTP headers (-> cookie exchange and stuff)
It is completely impossible for the server to verify this.
All interactions between the Javascript and the server come directly from the Javascript.
Therefore, malicious Javascript can do anything your benign Javascript can do.
By using SSL, you can make it difficult or impossible for malicious Javascript to enter your page in the first place (as long as you trust the browser and its addons), but once it gets a foothold in your page, you're hosed.
Basically, if the attacker has physical (or scriptual) access to the browser, you can no longer trust anything.
This problem doesn't really have anything to do with javascript. It's simply not possible for any server application (web or otherwise) to ensure that processing on a client machine was performed by known/trusted code. The use of javascript in web applications makes tampering relatively trivial, but you would have exactly the same problem if you were distributing compiled code.
Everything a server receives from a client is data, and there is no way to ensure that it is your expected client code that is sending that data. Any part of the data that you might use to identify your expected client can be created just as easily by a substitute client.
If you're concern is substitution of the client code via a man-in-the-middle attack, loading the javascript over https is pretty much your best bet. However, there is nothing that will protect you against direct substitution of the client code on the client machine itself.
Never assume that clients are using the client software you wrote. It's an impossible problem and any solutions you devise will only slow and not prevent attacks.
You may be able to authenticate users but you will never be able to reliably authenticate what software they are using. A corollary to this is to never trust data that clients provide. Some attacks, for example Cross-Site Request Forgery (CSRF), require us to not even trust that the authenticated user even meant to provide the data.
I have created server daemon, that produces some data, like messages and so. But, what im interested in - client monitoring. For example i have web page, and i need to establish persistent Tcp connection to server and show all incoming data into textbox. I know it can be done with flash, but im searching for JS implementation.
Is it possible and what`s the best practices ?
What you're asking for is known as Comet. Plenty of server software and client libraries exist - see the linked Wikipedia page.
WebSockets is designed to solve this problem.