So I'm making a app for a bank, but it doesnt manage very important data. I have two problems, it will run over a VERY large LAN network protected by all kinds of security(antivirus and firewalls) and the bandwidth in certain regions is as low as 56kbps.(Its a desktop app with a web server backend connected by web services)
From the security point of view all I want is to prevent someone from executing the web services from some other source or app results in change in the database . I'm thinking of each desktop app installed with a install code, this will be hashed and required as a parameter for every function call and will act as an authentication ticket? Is this good enough? Are they better SIMPLER means?
For performance, how do I measure or know if the web service will send and receive data at a decent rate?
Thanks
Gideon
Assuming you are on a windows domain. You could configure the server to use windows authentication and restrict the users which can access the web service.
For performance measuring - asp.net will show you a sample request and response if you hit the web service from a browser, you can work out the site of a message and use the bandwidth to calculate how long it should take. You could also call the web service and use the stopwatch class to measure the time it takes.
I would prefer assigning usernames and passwords. Either way, the user can disclose their code to someone else. And either the user or a recipient can access the app using other programs (there's no way to prevent someone extracting an install code). But if you assign usernames, they are more likely to take personal responsibility for what happens using the authorization.
Related
Sorry no code here because I am looking for a better idea or if I am on the right track?
I have two websites, lets call them A and B.
A is a website exposed to the internet and only users with valid account can access.
B is a internal (intranet) website with (Windows authentication using Active directory). I want Application B (intranet) to create users for Application A.
Application A is using the inbuilt ASP.NET JWT token authentication.
My idea is to expose a Api on the extranet website (A) and let (B) access this API. I can use CORS to make sure only (B) has access to the end point but I am not sure if this is a good enough protection? We will perform security penetrations test from a third party company so this might fail the security test?
Or
I can use entity framework to a update the AspnetUsers table manually. Not idea if this is feasible or the right way or doing things.
Any other solution?
In my opinion, don't expose your internal obligations with external solutions like implementing APIs etc ...
Just share the database to be accessible for B. In this way, the server administration is the only security concern and nobody knows how you work. In addition, It's not important how you implement the user authentication for each one (whether Windows Authentication or JWT) and has an independent infrastructure.
They are multiple solution to this one problem. It then end it really depends on your specific criteria.
You could go with:
B (intranet) website, reaching into the database and creating user as needed.
A (internet) website, having an API exposing the necessary endpoint to create user.
A (internet) website, having data migration running every now and then to insert users.
But they all comes with there ups and downs, I'll try to break them down for you.
API solution
Ups:
Single responsibility, you have only one piece of code touching this database which makes it easier to mitigate side effect
it is "future proof" you could easily have more services using this api.
Downs:
Attack surface increased, the API is on a public so subject to 3rd parties trying to play with it.
Maintain API as the database model changes (one more piece to maintain)
Not the fastest solution to implement.
Database direct access
Ups:
Attack surface minimal.
Very quick to develop
Downs:
Database model has to be maintained twice
migration + deployment have to be coordinated, hard to maintain.
Make the system more error prone.
Migration on release
Ups:
Cheapest to develop
Highest performance on inserts
Downs:
Not flexible
Very slow for user
Many deployment
Manual work (will be costly over time)
In my opinion I suggest you go for the API, secure the API access with OAuth mechanism. It OAuth is too time consuming to put in place. Maybe you can try some easier Auth protocols.
I work for a Canadian government department, and our group uses primarily tools from Microsoft, including Visual Studio. We need to carry out load-testing on one of our department's web applications. I have no prior experience with load-testing, but from what I understand, this would entail creating web performance tests recording various testing scenarios, and then creating load tests pointing to these web performance tests.
One complication is that our application relies on an external authentication service, a service used by other applications (and other departments). Our service agreement with this service provider explicitly stipulates that we not subject the service to load-testing.
So we'll need to find a way to bypass the authentication mechanism to carry-out our load-testing. Here's the outline of one strategy a colleague and I came up with:
Log-in normally to the web site, going through the authentication
service as normal.
Use developer tools installed in the browser to capture the cookie(s) created when authenticating
Create a web performance test, and add some code to the web performance test to use the cookie(s), and thereby use the session I
had established when logging in manually.
But I'm not entirely confident that this is the right approach. And even if it is - I have no prior experience with creating web performance tests or load tests, so I'm a bit lost as to go about programmatically loading a cookie inside a web performance test.
Does anyone have any suggestions?
I would break down the task into smaller pieces. If your main job is to load test the application, I would set it up on the internal network with Windows authentication or anonymous authentication, and modify the application to avoid having to deal with that part of the problem.
For the authentication piece of the problem, try set it up so a single static cookie will work every time. (If you need thousands of distinct user cookies, this becomes a bigger job, of course.)
See here for a discussion of the Apache JMeter cookie manager.
I would ask if the authentication could be stubbed out. Instead of calling the 3rd party, call a stub application which will return the equivalent responses. That way, instead of stressing the 3rd party, it's only your (self-hosted) stub that is affected.
This is the opposite of not having a front-end application; in which case a test harness would be required to emulate the front-end. A stub is the equivalent for emulating a back-end application.
I'm designing a database monitoring application. Basically, the database will be hosted in the cloud and record-level access to it will be provided via custom written clients for Windows, iOS, Android etc. The basic scenario can be implemented via web services (ASP.NET WebAPI). For example, the client will make a GET request to the web service to fetch an entry. However, one of the requirements is that the client should automatically refresh UI, in case another user (using a different instance of the client) updates the same record AND the auto-refresh needs to happen under a second of record being updated - so that info is always up-to-date.
Polling could be an option but the active clients could number in hundreds of thousands, so I'm looking for a more robust and lightweight (on server) solution. I'm versed in .NET and C++/Windows and I could roll-out a complete solution in C++/Windows using IO Completion Ports but feel like that would be an overkill and require too much development time. Looked into ASP.NET WebAPI but not being able to send out notifications is its limitation. Are there any frameworks/technologies in Windows ecosystem that can address this scenario and scale easily as well? Any good options outside windows ecosystem e.g. node.js?
You did not specify a database that can be used so if you are able to use MSSQL Server, you may want to lookup SQL Dependency feature. IF configured and used correctly, you will be notified if there are any changes in the database.
Pair this with SignalR or any real-time front-end framework of your choice and you'll have real-time updates as you described.
One catch though is that SQL Dependency only tells you that something changed. Whatever it was, you are responsible to track which record it is. That adds an extra layer of difficulty but is much better than polling.
You may want to search through the sqldependency tag here at SO to go from here to where you want your app to be.
My first thought was to have webservice call that "stays alive" or the html5 protocol called WebSockets. You can maintain lots of connections but hundreds of thousands seems too large. Therefore the webservice needs to have a way to contact the clients with stateless connections. So build a webservice in the client that the webservices server can communicate with. This may be an issue due to firewall issues.
If firewalls are not an issue then you may not need a webservice in the client. You can instead implement a server socket on the client.
For mobile clients, if implementing a server socket is not a possibility then use push notifications. Perhaps look at https://stackoverflow.com/a/6676586/4350148 for a similar issue.
Finally you may want to consider a content delivery network.
One last point is that hopefully you don't need to contact all 100000 users within 1 second. I am assuming that with so many users you have quite a few servers.
Take a look at Maximum concurrent Socket.IO connections regarding the max number of open websocket connections;
Also consider whether your estimate of on the order of 100000 of simultaneous users is accurate.
I have experience developing software and web applications and I have decided to do some freelance work on the side. Well, I met with my first client and they are requesting a relatively simple, custom system that (without being long winded) tracks client’s paperwork as it progresses through the business’s different manual processes. It is a small business that has about 10 employees, but all of the employees will interact with the client’s paperwork, therefore everyone would need access to the new system. When I say ‘track’ I literally mean that the employees will ‘check as complete’ on a simple page the increases a progress bar at different stages for the paperwork. Now I am %110 capable of coding the custom system that meets their needs, but I am unsure about how I should go about doing it.
The information that is being tracked in the new system and stored in the DB is confidential information that they are very protective of. My main question is how should I be developing this to be as secure as I can?
-They have their own server in house, so should I develop an application (VB and SQL) for the server and require employees to log on remotely to use it? Can more than one person access/use the application at a time?
-Or should I develop a web application (ASP.Net/VB and SQL) that is only accessible on their network to their employees? They plan to expand offices, could they set up a VPN to access the site?
I’m leaning towards a web application, but I have not done too much in term of security. Basically I’m looking for pros and cons for either option or any suggestions on what I should.
PS, stackoverflow is awesome! Long time user, first time poster!
If you want to develop using vb & sql you have to consider that:
You need to have real ip
Your system will communicate threw certain port and you have to handle the security measure for letting certain port opened in your server.
You should have good knowledge in network programming
If you want to develop using asp.net you have to consider that:
in case only office employees will use the system, you can develop against users in Active Directory and for outside users with username and password with SSL connection or vpn
for preventing more than one person access the file you can simply add column 'locked' in case file is being used.
Well im not a web fan (I suck) ive seen too many security issues go with it...i.e Lulzsec, but i do very much love VB apps.
So I would definetely recommend a VB app connected to a MSSQL database (coz it's easy to configure and havent seen any security exploits yet),my Chinese friend told me there is a way to access MySQL free databases.Now, allow remote access but make sure your Windows Firewall is also configured properly do look at all angles of security.
If I remember well there is an option in MSSQL to specify the IP addresses or is it MAC addresses that can access the DB so maybe input all of the 10 employees' IP addresses assuming they are static,if they are dynamic (DHCP) don't bother. And ask them to make the IP address of the server where you will host the DB on static.
If only 10 employees use the DB then limit the connections to 10. For now develop this when it comes to VPN you can make a Remote version of the App im sure that will come later right now focus on the basics. Also use Dotfuscator when you are publishing the app I heard it is very good.N also im suggesting the document/work order is received at the reception so that user will check in the document with specifics...if they are passing on the work order to the next user they should select the user and then THAT user may enter some sort of verification code unique to the user...im sure you can envision the rest from here. Now do I also get a cut from this?lol
I've been doing the same for years now, and I always take the website side, this days I go width ASP.NET MVC 4, it's easier, everything in their place and extremely easier to test and maintain.
The web application has a very big advantage to any standalone windows application, you deploy and upgrade only one application instead to maintain all the different versions once you start deploying windows apps, and they are harder to debug once you start to having different machines with different versions and so on...
so, Web or Win app = Web app, always!
All you need is a server that run IIS and set it up for using Active Directory (Visual Studio has that project already, simply create an ASP.NET MVC and choose the "intranet" template), it will set up everything for you, and all you need later is tweak the Active Directory connection string.
I also use a self-signed SSL to protect data between client and server, as I also make the apps available outside the office without VPN needed, as long as they login with their secure AD credentials.
And... audit everything into a secondary database, every action performed by a user since they login until they logout, every view, update or creating data witch .NET makes it simple if you create your Logging method to simple log messages and Stack messages on errors.
This will greatly benefit your employer and you when something goes wrong.
I would say to go with web application. Advantage using web application is, if they want to expand bussiness .. same can you do with you WebApp. But choose .Net over VB, going with latest techonology will help you resolve current challanges.
We are in the process of writing a native windows app (MFC) that will be uploading some data to our web app. Windows app will allow user to login and after that it will periodically upload some data to our web app. Upload will be done via simple HTTP POST to our web app. The concern I'm having is how can we ensure that the upload actually came from our app, and not from curl or something like that. I guess we're looking at some kind of public/private key encryption here. But I'm not sure if we can somehow just embed a public key in our win app executable and be done with it. Or would that public key be too easy to extract and use outside of our app?
Anyway, we're building both sides (client and server) so pretty much anything is an option, but it has to work through HTTP(S). However, we do not control the execution environment of win (client) app, plus the user that is running the app on his/her system is the only one that stands to gain something by gaming the system.
Ultimately, it's not possible to prove the identity of an application this way when it's running on a machine you don't own. You could embed keys, play with hashes and checksums, but at the end of the day, anything that relies on code running on somebody else's machine can be faked. Keys can be extracted, code can be reverse-engineered- it's all security through obscurity.
Spend your time working on validation and data cleanup, and if you really want to secure something, secure the end-user with a client certificate. Anything else is just a waste of time and a false sense of security.
About the best you could do would be to use HTTPS with client certificates. Presumably with WinHTTP's interface.
But I'm not sure if we can somehow just embed a public key in our win app executable and be done with it.
If the client is to be identifying itself to the server, it would have to be the private key embedded.
Or would that be too easy to extract and use outside of our app?
If you don't control the client app's execution environment, anything your app can do can be analysed, automated and reproduced by an attacker that does control that environment.
You can put obfuscatory layers around the communications procedure if you must, but you'll never fix the problem. Multiplayer games have been trying to do this for years to combat cheating, but in the end it's just an obfuscation arms race that can never be won. Blizzard have way more resources than you, and they can't manage it either.
You have no control over the binaries once your app is distributed. If all the signing and encryption logic reside in your executable it can be extracted. Clever coders will figure out the code and build interoperable systems when there's enough motivation to do so. That's why DRM doesn't work.
A complex system tying a key to the MAC address of a PC for instance is sure to fail.
Don't trust a particular executable or system but trust your users. Entrust each of them with a private key file protected by a passphrase and explain to them how that key identify them as submitters of contents on your service.
Since you're controlling the client, you might as well embed the key in the application, and make sure the users don't have read access to the application image - you'll need to separate the logic to 2 tiers - 1 that the user runs, the other that connects to the service over HTTP(S) - since the user will always have read access to an application he's running.
If I understand correctly, the data is sent automatically after the user logs on - this sounds like only the service part is needed.