321

You should implement input validation as a defense-in-depth method. So input validation should not be your primary defense against SQL injection, that should be prepared statements. As an additional defense you should restrict the allowed inputs. This should never ever restrict functionality. If there is a legitimate use case to have apostrophes in input, ...


315

Client side validation The validation code you have provided is in JavaScript. That suggests it is code that you use to do the validation on the client. Rule number one of securing webapps is to never trust the client. The client is under the full control of the user - or in this case, the attacker. You can not be sure that any code you send to the client is ...


40

Subresource integrity is not about protecting your own code of the web application against modification. What SRI is intended to do can be seen from the description of the goals: Compromise of a third-party service should not automatically mean compromise of every site which includes its scripts. Thus, it is about protecting your use of resources ...


36

First off, if someone exploited a file upload function, ensure that you're verifying the file on both the client and server. Bypassing client-side JavaScript protection is trivial. Second, ensure that you go through and implement these ideas from OWASP. That should cover most of your problems. Also ensure that you don't have any other unpatched flaws on ...


31

When you sanitize input, you risk altering the data in ways that might make it unusable. So input sanitization is avoided in cases where the nature of the data is unknown. For instance, perhaps some special characters hold significance in the data and stripping them means destroying that significance. A scenario like this may be that your system stores ...


29

The technical reason is to keep CRL size under control: CRL list the serial numbers of revoked certificates, but only for certificates which would otherwise be still valid, and in particular not expired. Without an end-of-validity period, revoked certificates would accumulate indefinitely, leading to huge CRL over time. However, since network bandwidth ...


27

It's clearly wrong in the context of injection attacks - either your database layer is processing strings correctly or it doesn't. Since apostrophes are valid in names and free text, blocking them entirely will break the application, and blocking them selectively wouldn't fix the injection problems. But strict input validation is good practice on general ...


26

It is super-important to note here that PHP was designed to be embedded in other content. Specifically, it was designed to be embedded within HTML pages, complementing a largely static page with minor bits of dynamically updated data. And, quite simply, it doesn't care what it's embedded in. The PHP interpreter will scan through any arbitrary file type, ...


23

You can disable PHP in your upload directory by .htaccess so your server won't execute any PHP code in the directory and in its subdirectories. Create a .htaccess file inside your upload directory with this rule: php_flag engine off Please note that the .htaccess rule will work only if your PHP server is running in mod_php mode. Edit: Of course, i forgot ...


23

Let's say you have a site built around jQuery. You don't download jQuery and use your copy, but you use a version from a CDN, making use of the caching on client's browsers. That works because if one site uses the CDN version, it will be cached and every site that uses the same version will benefit, not having to download an identical file every time. One ...


21

Escaping. Converting a control character to its escape sequence. For example, a < symbol may be converted to &lt; so that the characters following the < are not interpreted as an XML tag instead of XML content. Filtering. Like escaping, but instead of replacing the control character, it is simply removed. Validated. Comparison of an input ...


19

An intuitive and simple solution is to make sure that an automated script (malicious script) cannot try to register with a list of e-mails in order to figure out which ones are registered. For example, use CAPTCHA challenge as part of registeration to make sure it is a human trying to register an account. In this way, even if few user e-mails are tried, a ...


17

There is X.509, and there is SSL/TLS. TLS expects the server to send an X.509 certificate chain, from which the client will extract the server's public key. Then things diverge: In pure X.509, the server should send its certificate for the client to validate; possibly, the server may add an unordered bunch of extra certificates that could prove useful to ...


17

You shouldn't trust the client. Writing Javascript to stop characters being entered does not stop anyone from submitting them to your search. Your search routine should remove characters it doesn't support, and when printing that back out, it should show what it actually accepted, not what was submitted. For general purpose fields in a form, consider ...


17

Step 1) Parameterize your SQL. Step 2) Ensure you are using the SQL DB Connection library to set values for your parameters, not just setting them inline. This is the actual defense against SQL injection. Step 3) Don't do query building in SQL. That way lies madness. Step 4) add a config switch to propagate the error all the way back to the user. Turn it ...


14

Your approach - if used correctly - would protect you against two very common attacks: SQL injection and XSS. And escaping/encoding/prepared statements are definitely a must-have and your main line of defense. But as you specifically mention search boxes, your approach might for example not catch SQL wildcard DOS attacks (see here and here), which could be ...


14

Gee... "Sanitize output." I've never actually heard that term used before. I've been doing this for, oh, I don't know. Over a decade now at least. You don't "sanitize your output" you encode it for proper context within the application it is being presented. You encode the output for HTML, HTML Attribute, URL, JavaScript... I've never seen or heard anyone ...


13

It may have something to do with people embedding your captchas on a site they set up, and using the solved captchas to spam your site. For example, set up a site and give something for free (pirated movies/software, porn, etc) but ask for the captcha. Internally this is actually your captcha, and any solved captcha is passed down to a spambot targeting ...


12

Although the certificate has a finite validity period it can be revoked at any time. The act of revocation places the serial number of that certificate into a certificate revocation list (CRL). Each certificate will include a link to a location where the latest CRL has been published by the issuer of that certificate. This means that if a certificate is no ...


12

As far as I can tell, this scheme doesn't make any sense. As you've noted, you still need to store the plaintext email address for the user, so there isn't any significant security benefit to using the plaintext email and email + password + salt hash vs just using plaintext email and password + salt hash. As I'm sure you've already noted, without the ...


12

Prepared statements (parameterized queries) are great just make sure you implement it correctly. I've seen "prepared statement" implementations that were every bit as vulnerable. For discussion of implementation details I recommend stack overflow. Also nothing wrong with defense in depth (input validation in this case) but do it well...rejecting all ...


11

You are only checking the extension, this doesn't necessarily correlate to what the actual file type is. Server side you could use something like exif_imagetype to verify the file is an image. exif image type usage: http://php.net/manual/en/function.exif-imagetype.php


11

I'm not a security person. I'm a programmer who has to maintain secure code. This is what I call a "brittle" practice. Entry points are scattered all over a typical project. Finding and sanitizing all of them is a lot of work to address only a single problem, a lot of careful maintenance and hassle to ensure it remains effective as the code changes, and full ...


10

If this is a concern (i.e. if the fact of a person's membership would be considered sensitive information), one solution is to process the registration normally from the user's perspective on the registration page, but send a different e-mail out that explains that an account already exists/gives details on resetting the existing account (or replacing it if ...


9

There would be only a security flaw if it would be possible to leave the MySQL string literal context the $id value is inserted into and to supply arbitrary SQL fragments. And this is only possible if $id contains the plain ' that would denote the ending delimiter of the MySQL string literal: // resulting SQL statement with $id = "' OR '1'='1" SELECT * ...


8

You don't know how to sanitise data until you output it, or more precisely use it. In many cases it might seem obvious; in your blogging engine you want to filter out script-tags; always and ever so you simply delete them from the input and never think of them again. In other cases it might not be so easy; if the same data is used in different contexts. "&...


8

As you said yourself, if you're using parameterised queries, then the single quotes isn't a problem. In this case, you can reject their advice. If doing so, highlight the fact that you are using parameterised queries and that this aids usability as well (using your previous examples).


8

If you're 100% sure you always prevent SQL injection everywhere, this indeed is nonsense. However, SQL injection is one of the most common security risks, and even if you're sure you've properly written your application to use parameters, a sloppy DBA might execute a query that's at risk for second-order SQL injection. It might not even be stored anywhere, ...


7

From the iOS 7 Deployment Technical Reference document (opens a PDF): Certificate validation The first time a user opens an app, the distribution certificate is validated by contacting Apple’s OCSP server. Unless the certificate has been revoked, the app is allowed to run. Inability to contact or get a response from the OCSP server isn’t ...


6

The short answer is yes, you should always implement server side validations to prevent attacks. You can never trust client side applications as anything that is installed locally can be subverted by an attacker. They can also see what you are checking for, which gives them even more information with which to attack your server. Many exploits target ...


Only top voted, non community-wiki answers of a minimum length are eligible