Tag Info

Hot answers tagged

20

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


13

You should use prepared statements to prevent SQL injections. Take a look at this question. However, $_SERVER['REMOTE_ADDR'] should be a valid IP address as it comes from the server, as verified by the TCP handshake. See this question for an extended discussion on this.


10

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


8

Great question! You are asking the right questions. Short answer. In most cases, escaping at the output side is the most important thing to do. The best solution is to use a web development framework (such as Google ctemplate) that provides context-dependent automatic escaping and automatic defenses against other injection attacks (like prepared ...


6

Also, why is whitelist approach better than blacklist approach as mentioned by OWASP. Why not just block a handfull of characters used in XSS like < , > , etc Blacklists are static in the sense, they prevent 'known bad' from happening. The problem with this is, there are new attack vectors found everyday and you would need to constantly update ...


6

What is the implication of verifying it? The referer header: can be spoofed by the client can be completely omitted by the client (notoriously when going through TOR/proxies) is no guarantee that the user actually came from there There referer header is sent as a courtesy from your browser, it is not a HTTP RFC requirement. See here for details on the ...


6

A CSRF attack tries to exploit "the trust that a site has in a user's browser" (so says the Wikipedia page, and it is well said). It is about the server accepting a request from the client, on virtue of the request coming with some authentication characteristic which makes the server believe that it comes from the genuine user (which it does) and under the ...


6

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


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


5

Certificate validation is, huh, a bit more than looking at the dates. Have a look at RFC 5280. It would be an utter delusion to believe that you could implement certificate validation with any kind of security, and decent interoperability, if you do not read several times and wholly understand that document. A lot of crud has accumulated on the ...


5

That's why the character class [[:alnum:]] exists; it includes the characters which are considered valid alphanumerics in the currently active locale. Of course, that doesn't work well on a web server in the US when someone in Egypt is attempting to provide input through a form - and it doesn't work with punctuation. But it also doesn't include spaces, and ...


5

You need to verify that the HTML is valid (e. g. proper nesting of ", ', <, >). Otherwise different browsers will use different algorithms to "fix" it. This results in them seeing different things as tags. Furthermore there is a high risk that you add too much to your whitelist. For example the href attribute may contain active content. For example: ...


5

No, as it seems to indicate you are using jQuery (adept at parsing out information from HTML tags) to do input validation on the user inputting HTML that you will then display back to the user. Whitelisting safe HTML tags, and blacklisting unsafe HTML tags is the wrong method to preventing XSS. The right method is using a lightweight markup language like ...


5

From this page it looks like the REMOTE_ADDR element of the $_SERVER array is populated by the server as opposed to being passed by the client, so it should (absent any bugs) be a reasonable assumption that it is the IP address of the remote client (or a proxy server acting on behalf of the remote client). As @Lucb1e commented below some elements of the ...


5

ASP.NET Event validation does provide a decent level of protection against some specific web security attacks, but shouldn't be considered a panacea. There have been vulnerabilities in the implementation in the past like the ASP.NET Null Bypass and also there are cases where it may not come into play (examples here and more recently here). From that last ...


4

What is "output encoding", and can someone provide a concrete example of how a validation routine could make use of it? Output encoding means that the data is encoded appropriately for the context into which it is being placed. Example, say you want to dynamically display a name from an untrusted source : Your name is:<b>Foo bar</b> If the ...


4

It is not just a block of handful characters that you need to blacklist. In security we go by this dogma: "There are things we know that we know. There are known unknowns. That is to say there are things that we now know we don't know. But there are also unknown unknowns. There are things we do not know we don't know." Blacklist might help you ...


4

I think you might have rejected ESAPI too quickly. To defend against XSS, I recommend you do output escaping: any place where you insert data dynamically into an HTML document, escape the data (in a way suitable for that parse context). ESAPI provides libraries for the escaping and is very useful. This does not involve "changing your input". For more, ...


4

From RFC-2818 - HTTP Over TLS: Matching is performed using the matching rules specified by [RFC2459]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to ...


4

I strongly suggest to use existing frameworks to do validation on input, and escaping on output. Escaping on input has three big issues: You have to un-escaping and re-escaping for a different output media, such as a pdf file instead of a HTML page It is more complicated to introduce fixes because the existing (incompletely escaped) data needs to be ...


4

Without certificate revocation, your only way of validating a certificate would be to make sure the dates are good and that the CA that signed it is trusted. What if you issued a client certificate to a user for VPN access and that certificate was misplaced or stolen? What if a server was compromised and the certificate no longer trusted? Certificate ...


4

In addition to what @Tom Leek's said about the certification path API, it seems that you're talking about "TLS certificates", which I presume implies you may be using your X.509 certificate within the scope of TLS. To do this as part of Java's TLS stack (JSSE), you can use the existing X509TrustManager infrastructure. I must admit I'm not sure whether it ...


4

To avoid this kind of leak, you could also begin the registration process by asking for the e-mail. After entering it, you would send an e-mail with a link so that the user could continue with the registration process. If the e-mail was already registered, you would send an e-mail saying that. That way, only the owner of the e-mail could register. ...


4

These are the valid range for standard encoding of track 2, which is the ABA standard: 0x30 to 0x3f in the ASCII character set 0 1 2 3 4 5 6 7 8 9 : ; < = > ? Sources: http://blog.tehinterweb.com/?p=60 With enough control over the reader/writer, you can encode bits in anyway you choose though, could make up any system you like.


3

REMOTE_ADDR is determined by the receiving TCP stack - it's not data 'sent' by the client. Neither IPv4 nor ipv6 use characters which are unsafe / delimit expressions in SQL. However there's very little point in storing the IP address (i.e. xxx.xxx.xxx.xxx or xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx) the numeric value is far more useful and requires less ...


3

Ideally all three. Assume that, at some point, the developer working on the input screen will leave out a check (or more likely that some new exploit will come along that breaks the check). The difficulty with validating at input is that if a new exploit comes along, you may have already accepted malicious data before you can fix your validation. Assume ...


3

Some variants of Password Authenticated Key Exchange (PAKE) allow for mutual authentication using a password; also take a look at Zero Knowledge Password Proofs. Here the server still has the user's password (created during account setup), but during key exchange the client doesn't give the server the password, rather the client and the server run a protocol ...


3

No. It is not safe. Browsers vary widely in how they parse certain kinds of input (for especially "invalid" HTML, where "invalid" here is not especially well-defined, but sometimes even for "valid" HTML). This provides a large number of subtle ways to smuggle bad HTML into your HTML document, without jQuery realizing it. The root of the problem is not ...


3

There is the time of signature, and there is the time of verification. Let's first simplify the situation: we assume that the current date is 2009-07-08. For that value of "right now", the RootCA and SubCA certificates are still valid, but Alice's certificate is not. You see a signature which is purported to have been produced by Alice on 2009-05-01. If you ...


3

A lot of this will depend on your environment, but this is a generalised list I've used before (I've included compliance stuff under each point): All software patched and linked into a patch manager Your patch manager should patch often and alert loudly if a machine falls out of compliance. All unnecessary ports closed Set up nagios or similar to run a ...



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