Tag Info

New answers tagged

0

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 ...


1

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 ...


0

No, because SQL Injection and Insecure Direct Object References includes the case of 'ability to run SQL that the user has access to but the application was designed to not allow'. Your method will limit the ability to get at stuff outside their permissions, but in most cases that includes things that aren't intended to be open, as well as system ...


1

Not effectively, no. You're always going to have cases where row-level security can't properly emulate the business processes. You'd also need to have a lot of "general purpose" accounts for things like user signup. The whole thing would be convoluted, difficult to maintain, and largely ineffective. Keep in mind, also, that SQL injection potentially does ...


0

The "constantly regenerating pepper" component feels like too much complexity for the relatively niche attack scenario it protects against. It seems to me that the moving parts required to support it are more likely to introduce an attack vector (or a scenario for unrecoverable data loss) than protect against one.


0

A little late to the party - I recently read that the reason for this is that for many banks, the value of the increased security of allowing those characters is outweighed by the implementation cost and the support cost of dealing with customers that cannot remember their passwords. I'm not saying that its a good reason, but that is how I interpreted ...


0

First off, there are ways to mount encrypted partitions without having to enter the passphrase manually or storing it on the system that is being protected. Look at Mandos for one example of this; it's basically a client/server application that stores the key to unlock the encrypted container separate from the container itself. An attacker would at the very ...


2

For IPv4, there isn't a good option. The address space is effectively entirely in use, so any partial storage means that one person voting can potentially block others from voting. The numbers towards the left generally represent ISP, geographic area, etc. -- things that an attacker might be able to figure by other means. The numbers towards the right ...


0

Assuming you run the web server as its own user, then only root and that user can read your OS Environment Variable. Unless you're using 30 year old AIX or something. Even Windows protects envvars. If you encrypt the values, how are you going to secure the key? The key could be read by the user or root too. If you store the values in a file, how is that ...


1

You have to distinguish between the account used to connect to the database and the original user's account: the service account used to connect the application to the database should be used to constrain access to those schemas and tables that are to be accessed. The service account should focus on security aspects such as preventing DROP or CREATE TABLE ...


1

Your question is a little vague, so I would advise that you consider what threat models you're trying to protect yourselves from. The first thing to do is to define that a DMZ is a region in your network which is considered wholly or partially untrusted, because it is attached to the Internet (or some other untrusted and hostile network). The DMZ defines a ...


-3

It is better to NOT use a DMZ at all. but if you must, assume everything in the DMZ is compromised and should be distrusted and assumed leaked to others. therefor the best solution would be to move your DB and webservice outside of the DMZ, and employ a reverse proxy inside your dmz. (and make sure the webserver can only talk with the proxy, and the DB only ...



Top 50 recent answers are included