I have a web page of asp.net using c#.I am now want to implement the hardware security that any hardware identification should be fullfiled before opening the web page.I meant if allow the that hardware of client then it will open the web page otherwise it should make error of authorization etc.Is there anywat to do this that i can detect client hardware identificaions and then allow to open the web page.Plz help !
No, there is no way to detect the client hardware directly through the browser.
The User-Agent http request header can give some information about the user OS, but still remember that users can modify and send whatever headers they please. Not something you should count on for security.
The web does not allow you to lock users to hardware, and it is IMO a bad practice.
You can at the server keep track of active sessions, and allow only a certain number of sessions per user.
Related
In my QT application, I need to download certain data. This data is protected and users need to Login to the website to download the data. In order to allow users to login, I display the Login Page of our website using QWebEngineView. The user enters his credentials. This generates the required cookies for authentication. I store the generated cookies in QNetworkCookieJar. I then create a QNetworkAccessManager and add the saved QNetworkCookieJar to QNetworkAccessManager. I then use the QNetworkAccessManager to download the data. This all works fine. However, in the security review of my project, there were concerns raised that the Login page is under the control of my application and thus I can get the user credentials (for eg. by watching the keystrokes on Login Page).
So my question is: Is this security risk real? Can I actually get the user credentials? If yes. what options do I have to authenticate the user and still avoid any security loopholes?
Yes, in a Qt Application you can always catch any keystrokes sent to a widget. The same applies to Google Chrome and almost every web browser out there. The user enters the data in the application and it is passed through to the network and across the wires to the web server.
When considering security risk you always consider two things. The potential damage and the feasibility of crafting an exploit. The potential damage is high and you can't control that. What you can control is the feasibility of creating an exploit. Considering that you (or your company) control the code, you can make it very hard to exploit the fact that your application knows the credentials. That would make the risk very low.
Even employing something like a hardware dongle would be problem because you have to transfer the data from the dongle to the the web engine. That still can provide a way to intercept it.
Try looking for discussions on software security risk analysis and mitigation. There is even an SE site about it, https://security.stackexchange.com/.
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).
Focusing on clients who can not afford PCI compliant servers I intend to limit credit card information to a form entry that posts to the gateway via SSL. I do not store CC info on my clients shared server. My question is about the ASP.NET web form that uses server controls and if form information is in any way run through my clients shared and potentially unsecure server just by using form elements with runat=server. In this form I am using plain html input elements to collect the CC#, CVV# and expiration date but the submit element uses runat=server as I have logic in the code behind that limits the visibility of the button if a condition is not met.
If the form on the shared server accepts card details then that server & network must be PCI compliant, the fact that the details are not stored doesn't matter. Given that its a shared server achieving compliance will be virtually impossible.
The best way to keep card data away from the shared server is to have its page host an IFrame for a page thats hosted on a dedicated, compliant server.
If you never have any postbacks that should work, but if you do have any controls that support postbacks, the cc info will possibly be included (depends upon viewstate).
It sounds like you're going to have access to the cc info, as otherwise it doesn't make sense to make the button visible or not...
I have my website, and it records the number of visitors, IP and time of access...
I want to identify each visitor... I think that this was possible recording IP Address... but when the IP is dynamic, my system fails. So I think that I can solve it recording MAC address... is possible? What language should use? PHP, ASP, Javascript?
Thanks
Edit: What I can use to identify each user without having login information (username & pwd).
The MAC address, by TCP/IP standards, is never communicated outside of the local-area network to which it pertains — routers beyond that LAN don't even get the information you're trying to record.
There are many other ways to try and identify unique visitors, including matching the user-agent's details in addition to the IP, serving cookies as part of your response, etc… it is, after all, a core functionality in the field of "web analytics".
MAC addresses are simply not part of the gamut of techniques that it makes sense to utilize for it!
It is only possible if you use a technique where you install a "native" app on the client machine. For example, an activeX component, java applet or a client application. Then that application, once installed can get the MAC and then call to your web server with the MAC as an argument. In other words, you have to build your own front end "browser" to handle logging in. Then once the user is logged in, you can launch the app in the default browser.
It would be nice if future browsers allowed users to give permission to specific sites to access the MAC. Then if a site had a button that said "Register this device" the web application could do so without needing an additional native app installed (after all, the browser IS a native app).
Can't you just have them store a cookie, so that when they come back they can be uniquely identified? No username/password requirement.
http://en.wikipedia.org/wiki/HTTP_cookie
Sorry but sending MAC address isn't part of the HTTP. However, you can use cookie to identify different users. Any backend language will do (add cookie in the server side). You can set the cookie in the client side using JavaScript too.
The purpose of using a Javascript proxy for the Web Service using a service reference with Script Manager is to avoid a page load. If the information being retrieved is potentially sensitive, is there a way to secure this web service call other than using SSL?
If your worried about other people access your web service directly, you could check the calling IP address and host header and make sure it matches expected IP's addresses.
If your worried about people stealing information during it's journey from the server to the client, SSL is the only way to go.
I would use ssl it would also depend I suppose on how sensitive your information is.
I would:
Use SSL for the connection
Put a time and session based token in the request
Validate the inputs against expected ranges on the server
SSL prevents man-in-the-middle
Tokenized requests verify that the request is coming from an active and authenticated session, within a reasonable amount of time from the last activity within the session. This prevents stale requests being re-submitted and verifies that it came from the source of the session (store the IP address, user-agent, etc on the server for session management).
Validating that the inputs are within expected ranges verifies that the request has not been doctored by the party that you are talking to.
Though SSL would be best, there are a number of client-side cryptography libraries that could alleviate some of the security concerns - see https://github.com/jbt/js-crypto for a nice collection