I'm very new to web services (please note, not WCF but the old fashioned .asmx files).
Now I may be liking this too much to ports, but if I expose a port on my web facing server then it is exposed to attacks as well as my own use; There are tools which can scan to see what ports are open.
Is this true of a web service? Now, don't get me wrong, I know each service should be coded well enough that nothing malicious can happen or that the calling class doesn't know the 'contract' to implement them, but that's not the question (and I guess port flooding could still occur?); If I put up a few web services on a server, is there a tool/program which can detect them (by name)?
Yes, a web service is basically a web page that takes arguments and response with a formatted result that can be read more easily by a program (technically both are a result of a http request and response - there are other mechanisms as well, but the typical one is over the http protocol).
If you type the link to your web service in a browser you will see you are presented with an interface that allows you to "execute" its services.
Therefor you need the same security as with a web page, meaning login or check of credentials, tokens, signing, encryption and so forth (preferably on a ssl-connection).
Related
If browsers use http to connect to server ,and in any web application when we hit the URL and the request is received by a controller mapped to the URL ,can we say browsers are also rest client
That would depend entirely on what you use as a browser but generally no, a browser lacks meaningful tooling to probe a RESTful server out of the box, and comes with features that otherwise would not be needed by a REST client application, so would not be considered a REST client. A browser might be considered as a more generic HTTP client, but even that does not fully describe the problem domain of a browser (rendering, scripting, etc.). Even if you build a web interface to probe a REST service by submitting forms, that does not make the browser a REST client, but instead your website/web application would be the REST client application.
Yes,
the protocol the browser uses to communicate with the webserver clearly initially is a restful protocol.
Nothing more is necessary.
But it can get a bit more complicated.
The browser can fetch application code (javascript) in a restful way (e.g. GET) and execute that code which further can be communicating (Ajax) restful.
I know this question can be too generic but for purposes of narrowing the question, here is a brief description:
I'm planning to forget about ASP.net UpdatePanel and move to use ajax via JQuery. I am afraid that because of the plain, client-side nature of JavaScript (and consequently JQuery code), any one looking to my web page's source can realize what is the URL of the web services I'm calling and also what are being passed to those web services.
When using UpdatePanel for these types of operations, I'm sure that calling web services is done on server-side and I have no concern regarding issues of information on calling sensitive web services being exposed publicly but now that I'm planning to use Ajax via JQuery, It worries me alot.
Are my concerns reasonable and if true, what are the best solutions for avoiding the threats of web-service-calling-info being exposed?
Clarification: when saying UpdatePanel, I mean utilizing a chain of techiques including ASP.net AJAX, code-behind and relying on server-side Dlls for performing async server-side operations instead of jquery Ajax which requires web services for intracting with server.
There is no way on the internet to protect your web services all the time by just hiding the URL. I am not sure when you say your updatepanel does the web service call from the server you are not taking the true power of AJAX.
One way to secure your web service is to use the authentication in the web service side. For example you need to send some authentication key every time you access the source, and this is very common, you have so many public web service who protects it self using auth key like OpenId implementation. In case you do not want to change the web service logic I think jquery way of AJAX is not a secure option.
Here's a thought, you can have two levels of web service, one which will open for all that you can use in the jquery. From the current web service, from the server side call the other secure web service. Even now you can configure your incoming request for some specific machine IP.
In this case other than your own server no body else can access to the web service securely kept behind the firewall. It is something similar we do while connecting to database server from application server.
Let me know if this helps.
I'm going to state the problems my answer is hoping to solve:
Assuming you host your services on a machine other than the web server, the problem is you give potential attackers the name/address of those machines.
Attackers can write scripts/bots to scrape your data.
Attackers can focus on your web services and try to hack them/gain access to your network.
Attackers can try to perform a DoS/DDoS on your web services.
The solution I've used in the past is to create a light weight proxy on the web server such that all AJAX calls simply point back to the current domain. Then when a call comes in, it is simply routed to the appropriate web service, which is hosted somewhere internally on the network.
It creates one additional hop on the network, but it also has these benefits:
It hides the actual IP of the machine hosting your services.
You can easily lock down that one web server and monitor unusual activity. If you see a spike in activity, you can potentially shut down the web services. (If you use a different machine, you'd have to monitor two boxes. Not a huge problem, but easier to monitor just one.)
You can easily put a distributed caching layer in the proxy. This protects you from load/denial of service (DoS) attacks and obviously supports normal web service traffic.
You can hide the authentication at the proxy level. The public calls won't betray your authentication scheme. Otherwise an attacker can see what tokens or keys or secrets or whatever that you use. Making a proxy on the web server hides that information. The data will still flow through, but again you can monitor it.
The real benefit in my opinion is that it reduces the surface area of your application which narrows what an attacker can do.
Since you refer to ASP.Net, know its viewstate can easily be decrypted. There's no failproof ways to protect your code (not to say urls called).
If you're web services are called with some parameters that could allow unrestricted and dangerous actions, then you'd better start using some users/roles/rights management.
If you're worried about "man in the middle" attacks, you best option is to use https.
I have a web based application that uses lot of client side requests in various .asmx files.
I am wondering if I can use those web services only from client side and restrict the requests from other sources.
The reason for this is because I want to use those web services only from the current application and to restrict requests from other sources. For security reasons I could use soap authentication but since I requested the services from client side, I don't think the authentication it matters.
I'll appreciate any comments.
Thanks
The webservices are by definition public, publicly visible and available (unless they run on private network or standalone computer). I.e. anybody can access them. So, just deploying a webservice and hoping for the best is not a good approach.
And how do you intend to restrict other access?
Something I can't wrap my head around is how secure web services are.
For example we're writing a desktop application that will interact with data on one of our websites as well as local data. This data is sensitive though and the last thing we want is anybody calling the web services.
I've not yet found anything that says web services has some kind of authentication methods and the only security I've seen people talk about is using certificates to encrypt the message.
I'm no guru on this and would appreciate anyone's input and perhaps a link to somewhere that will explain this in simple terms.
Thanks
Jacques
If you are using ASP.NET to create a response / request Service you have only 3 options
ASMX
WCF
Normal .NET pages (or handlers) to process requests
as you specify Services, you can choose between ASMX and WCF then (you can read the difference between ASMX and WCF in my answer here)
keep in mind this
ASMX is considered deprecated technology and replaced by WCF. So if you are going to start new development which requires exposing reusable services, WCF is the way to go.
This days, there is a common pattern when we need to secure Services, and that's using a session key.
The Service normally has a Method for Login where it gets a User and some kind of Password (normally hashed, salted, etc) and that returns a "ticket" that has a limit of time (slided or not - means per each call to a method the period get's reseted or not), and all calls need to have that ticket included in the message body.
Services API like Magento and others uses this.
Or having a pre generated key that is given to the user / application to be used with every call
Services API like Campaign Monitor and MailChimp and others uses this.
The other normal way is to have the user and other credential in the message header all the time.
Services API like SuperOffice CRM and others uses this.
None of this services uses SSL, as I would only use if I really needed to protected the data in the "wire" keeping in mind that SSL expands the response time on every call made.
I hope this helps
Authentication:
Consider securing your web services with SSL. Distribute client certificates to those who need to consume those web services. Configure IIS to "Require Client Certificates".
Authorization: Consider developing a scheme where the user is sending a username and password of some kind in the querystring. When you can determine that those credentials are permitted to perform the operation that they're requesting, you can allow them to proceed. Indeed, this is custom logic that the application developer needs to write. There are no built-in conventions in ASP.NET web service for this.
The SSL encryption occurs at a lower level from the application. It's the applications job to then determine who is allowed to perform what operations.
Our webservices are encrypted through SSL (the certificates part) which is https://www.yousite.com instead of http://www.yoursite.com. This just provides basic encryption for the data stream. See SSL.
They are also authenticated by the authentication method that is chosen for our website. If it's is windows auth, or forms auth. See the msdn page on ASP .NET authentication.
For XML Web-Services you should take into account the following best practices:
Secure the transport Layer: the infromation or data in XML cannot be interrupted and read in transit.
Mask internal resources: Use Network Addres Translation (NAT).
Implement XML filtering: With the heklp of XMLand SOAP, affective filtering policies can be set to a content level that requieres a fully parsed or processed XML document.
Validate, Transform, Sign and Timestamp al messages: Use XML Schemma Validation, use XSLT for transforming XML, sing all messages, use Network Time Protocool (NTP) for synchronizing all XML nodes to a single authoritative reference time source.
Encrypt message fields.
Implement secure auditing.
Use existing security methods such as HTTPS.
Perform XSL transformations on the server.
Source: EC-Council Secure Programmer.
To expound on previous answers: Web Services are as secure as you make them. In general, there are two types of security. Securing the Transmission, and securing the access. Use of SSL can make your transmission secure (). Using Authentication (demand a username and password) allows you to secure access.
Web Services accessed via public internet (that is: not a VPN or only internal resources) are, indeed, less secure than Windows applications, since anyone can have access to them and, potentially, attempt to break your security. By using both transmission and access security, you can mitigate that to acceptable levels (acceptable to the point that banks use them for financial transactions, and you don't know paranoid until you've talked to a banker who has to face an FDIC inspection).
All web applications are exposed to the attacker and are a great surface area for attack. The biggest problem with web services, such as SOAP(WCF) is that often times the programmer doesn't realize that its trivial for an attacker to gain full access to the service. Often times programmers expose nasty functionally like execute_sql_query().
You should read the entire OWASP top 10.
Here's a primer on Securing XML Web Services Created using ASP.NET.
Scenario
I have an HTML/javascript website that uses javascriptSOAPClient communicate with an ASP.NET 1.1 web service in order to read/write to a SQL database. (http://www.codeproject.com/KB/ajax/JavaScriptSOAPClient.aspx). The database contains anonymous demographic information--no names, no credit cards, no addresses. Essentially the data collected is for data mining purposes.
The site is live, but we want to introduce a more secure communication between the javascript/ajax client and the wbe service for both this and future projects. Working as contractors in the financial industry, at some point we're going to get nailed with the question: is this website hackable? If we don't have a solution we could be out on our ears.
I am already following best practices such as communicating with the database via command parameters and stored procedures). However, currently anyone could browse to our web service description and figure out how to consume our exposed services.
Questions
With my hybrid solution (i.e. not end-to-end Microsoft) how should I go about authenticating client requests on the web service?
If I start passing a username/password or some other identifiable element into the web service as authentication, should I be concerned about how that key is generated/stored on the client side?
A few suggestions to consider:
List the threats, and compare each to your current setup.
Use SSL / HTTPS. This alleviates a whole class of vulnerabilities.
Use username/password, generated on the server side and sent out of band (in the post or by phone) to the user. (Hope this answers question 2).
Use 2-factor authentication. To do this, you can look at security tokens such as RSA's keyfob-type gizmos or look at Steve Gibson's Perfect Paper Passwords
The easiest solution from a programming standpoint is to use two way HTTPS. That is, the server presents a certificate to the client, and the client presents a certificate to the server. Then only clients with proper certs (issued by you) can connect.
That helps reassure clients that your site is not generally accessible, yet the security is transparent to the application and, once they've signed up and received a cert, to them. The downside is that you have admin overhead in issuing and tracking the user certs -- but that's probably less than you'd have dealing with username/password combos.
There are a few simple options:
SSL + Cookie
If the web app is also ASP.NET and hosted along with your web service, then you should have access to the User/Membership/Session of the web app inside your web service (essentially #1, but you get it without doing any work).
If the web app and web service are not on the same domain, then cookies are out due to cross-domain issues - so you can have the web app embed a GUID into a hidden form field, and use that GUID as a sort of cookie (and it will need to be passed as a parameter on all web service requests).
Can you incorporate a certificate authentication mechanism? So that only clients that have keys you can verify can communicate? That's how the product I work with has its managed devices communicate back to the core.