New answers tagged web-service
Any input to the user, whose content may be used in a database query is a possible vector of SQL injection. For example, with your example URL, depending on your server implementation this might work: https://testurl.com:1234/webservicename?parameter=DROP TABLE users;SELECT The key to preventing SQL injection is simple and we'll understood, always use ...
SQL injections have nothing to do with whether or not your application accepts URL parameters. They work with any input, be it the URL, the request body, a cookie, an HTTP header or even data from your own application (e. g. a string stored in your database). It doesn't matter. So it's not about the origin of the input. It's what you do with the input. If ...
What you might want to have is a passwordless access to the ssh service. This will stop brute force attempts on the ssh service. Of course if your machine is compromised to begin with, then you'll need a larger proverbial boat.
The app will keep user credentials (login and password) encrypted in a local database. I'm not sure which encryption scheme to use though. Don't encrypt the password, hash it. Ideally using something like bcrypt. I'm considering either a long duration multi-use token or short duration one-time tokens. The shorter the better, in order to reduce ...
Top 50 recent answers are included