General Question on FIPS requirements I understand that FIPS addresses cryptographic operations.
My question is, is it addressing exactly this?
For example, can an application loading a keystore use a non-FIPS provider?

Any input or relevant references is appreciated

For example an application loading a keystore using a non-FIPS provider, is it something forbidden or am I confused on this?

I think the definition of FIPS might help: Federal Information Processing Standard. The key here is Standard, much like a W3C technical report, ISO standard etc. You are not under any obligation to conform to these standards. Just look at web browsers. You are more than welcome to do your own thing. It isn't necessarily wrong not to conform to these standards.

But, there is always a reason for these standards. For one, conforming to them means you ought to be able to interoperate with other conforming software. For example, take C99, the ISO C standard. Any C99 code I write ought to work on any C99-compliant compiler.

In the case of cryptography and information security, I would really advise following these standards. For starters, they define how an algorithm or key store should behave, meaning not only interoperability but usually a reasonable level of security testing too. In other words, you know your environment (that you've just implemented) ought to not contain any weaknesses, library, OS and environment issues non-withstanding.

As an end user, you know your FIPS-compliant key store should give you some assurance of security, as opposed to whatever storage format Joe Bloggs dreamed up. You should find your software has some level of interoperability (for example, different standard, but many programs can read PKCS#11 keys and OpenPGP keys).

So it isn't forbidden per se, just really highly recommended. If you're choosing software, I would favour something that follows FIPS, PKCS or OpenPGP.

Another point to mention here is that FIPS, RFCs etc often define a usable part of what's out there (by way of a standard). Rijndael != AES, for example. The Rijndael cipher supports many more key lengths and block sizes than AES does, but simplifying that to a certain subset means it is simpler to implement, and that is exactly what AES (FIPS 197) does. What would happen if you said "implement Rijndael" is that many developers would not implement certain sizes due to time constraints, pure laziness or whatever. Software using the exact same core algorithm would then otherwise be incompatible.

So as a final answer, no it isn't forbidden, but it is highly recommended. Mostly, it is about interoperability, but there will be some level of assurance ("we're not recommending a broken cipher" (in current FIPS as opposed to retired ones)) too.


Does putting in quarentine attachments with two dots increase security in Outlook 2010? Outlook 2010 and antispam systems already forbid executable attachments.

In this scenario, does putting attachments with two dots in quarentine increase security? Attackers used to use this technique in order to make users believe they open an image when they are opening an executable.

Example: "cute-kittens.gif.exe" and "kernel-update.tar.gz"

Yes, but there is a difference. While "cute-kittens.gif.exe" can raise some eyebrows, since a GIF shouldn't be executable, I wouldn't say the same about .tar.gz files. To be more clear, .tar.gz should be considered as dangerous as .zip.

In fact, since any compressed archive coming from a Unix-like system is usually .tar.gz, a .tar.gz file could have a reasonable justification, such as a compressed archive of pictures, whereas I don't think a .gif.exe could be justified in any way. Much in the same way, a .txt.gz file could simply be a compressed text file, and should not be viewed as suspicious just because of its extension.

It is true that compressed archives (even .zip, .rar,etc.) can be used in order to complicate the AV scanning process, for example by sending a password-protected archive or by deploying a zip bomb, so putting in quarantine compressed files may be a good idea. However, this doesn't depend on the "double dot" extension, but simply on the fact that they are compressed files.

TL;DR Files with extension ".X.exe", where X is docx, pdf, gif, jpg,etc.  should always be blocked. Compressed archives having extension.tar.gz extension are no more dangerous than a zip archive. If Outlook only quarantines .tar.gz files, as opposed to zip, rar, and so on, this is wrong.


Are private keys generated by different software packages compatible? I know that GnuPG follows the OpenPGP standard, but if I generate a public/private key pair using GnuPG and upload the public key to a key server, i.e. the one at MIT, or use it to sign files, packages, etc. will other users who use OpenSSL, GnuPG, Putty, etc. be able to use it or descrypt the signed packages? Or do I need to generate separate public/private key pairs in all of these packages and upload the public key separately?

Usually you do not upload private keys on key servers, just public keys... private keys are meant to be, well, private. No point in shouting them far and wide.

OpenPGP is a standard format for messages and keys. The mathematical object which is a RSA public key (technically a list of eight integers for the private key, two integers for the public key) can be encoded in many ways and OpenPGP is one of them. GnuPG follows this format.

OpenSSL is a library (and some command-line tool) which was primarily focused on SSL/TLS and includes implementation of cryptographic algorithms. SSL uses public keys in X.509 certificates, which is another format, quite distinct from OpenPGP. Same kind of mathematical objects (RSA keys...), but different encoding. GnuPG internally uses OpenSSL for the cryptographic algorithms themselves, but applies its own encoding.

PuTTY is a SSH client which uses again keys (RSA, DSA...) with yet another encoding format. Again, the same mathematical objects are represented as distinct sequences of bytes.

Some people are working on bridges between these competing formats. It is still a great source of inconvenience.


How to check if some encryptions are disabled in OpenSSL? I want to check if the following encryptions are disabled in the openssl-1.0.2l

TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA

Are there a way to check that?

If you want to know which ciphers are available within your openssl binary just run openssl ciphers -V 'ALL:eNULL'. This shows you all ciphers available and the details, e.g.

0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
0xC0,0x2C - ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
0xC0,0x24 - ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
....

If you instead want to know which ciphers are available when using a specific cipher string inside the server use this cipher string instead of ALL:eNULL. Note that you need to make sure that your server and the openssl binary actually use the same OpenSSL library - and the exact same library build (i.e. same *.so file) and not  another library with the same OpenSSL version number.


Website Defacing without hacking (google issue or trick?) When I search in google for:

  "sensors"

The two first results are:

  "Sensors"
  "Publications"

If I click on these two lines (the second one for instance), I get to a defaced website (actually, there is an extra document.location() redirecting me to a Russian website).

However, If I go directly to the webpage :

  http://index.php/en/publication/9-publications-2014

The website is perfectly fine, and does not look hacked.

I tried with several computers (Mac, linux and PC), and from different networks (using IPSec VPN tunnel) all results are the same.

How does this hack work? How can I fix it? Is it a google-side issue?

EDIT:
After looking into the issue more deeply, I have found that the redirection seems to occur when google is set as the referrer.
This could be a trick to hide the hack from the webmaster (who access the website directly) but show it to the rest of the world. Have you heard of such strategy?

Yes, trying to hide hacks from the operator of a web site is common, and checking referer* is one way to do it.  If you can find a contact for the web site, it would be polite to report the hack so they can remediate. Edit: I've sent email to the "info@" email address.  If you know someone there, you might mail them directly, especially if you can write in German.

* I know it's correctly spelled with two Rs, but there's only one when it's a web "referer."  Fun facts to know and tell your friends.


Is there any way of making an SQL server think I'm accessing from localhost? The title is pretty much self explanatory

If a SQL server only allows connections from localhost, is there any way I can access from the outside by making it think I'm actually accessing from localhost?

Obvious answer: Make a local connection.

In other words, unless the network stack (of the operating system) is buggy, or someone grossly misconfigured e.g. port forwardings on the machine your database runs on, the only way to do that is by actually opening a connection from the machine your database runs on itself.

Now, in the year 2016, I'd say it'd still be totally unacceptable to offer unauthorized access based on host alone – you simply don't do that, since there's no cost to authentication.

A proper way of doing "safe" local-only networking is to not use IP sockets, but good ol' unix sockets, which can be secured using normal file access privilege systems.


Are there volatile memory chips which dont retain data after power off? It was demonstrated that dram modules can retain information up to 10 min after power off in certain conditions. My question - are there memory types which will retain data 10 sec at max even if being frozen (aka cold boot attack)?
EDIT. I want to secure my code on a colocated server and avoid cold boot attack and perhaps something else which I havent heard of yet :).... My idea is to split my program onto 2 pieces and run one on a separate CPU with its own memory (the example is GPU or FPGA). However I need to find out which type of memory can be erased almost instantaneously on power off before I can take another step.

I don't think you're going to find a type of RAM that is secure against cold boot attacks.

It may be possible to build application-layer defenses against this, by ensuring that all sensitive data stored in memory is stored in encrypted form.  Then when you shut down, you simply need to securely overwrite the decryption key.  However, this is likely to have significant performance and implementation costs, and I would question whether it is worth it.

I think you need to do some serious introspection to determine whether the cold boot attack is really a likely attack against your system.  Security always needs to be directed by deliberate risk management.  With some risks, the best approach is simply to accept the risk.  Alternatively, you may be able to mitigate the risk by providing physical security.  For instance, if you have super-sensitive data, perhaps you don't want to store it on a machine at a colo facility: perhaps you should keep it on a machine on your own premises.

If you want to tell us more about your specific application needs and scenario, and share the risk analysis you've already done, we may be able to provide more concrete suggestions.  But for now, my initial reaction would be to suspect that you're over-thinking it: for most people, the cold boot attack isn't really worth worrying about.


Why are passwords with special characters considered more secure than longer length passwords? For example, OWASP considers 10-128 characters, with lower, upper, digit, and special characters (I don't get why there's an upper limit). Using the OWASP's minimum guidelines and assuming there are 28 special characters, the entropy is 3e19. But with a 16 character password with only lowercase letter is 4e22. Throw in upper case and it's 2e27. Computers can calculate at a pretty fast rate but whatever it is, it lowers that entropy, meaning that the difference isn't 22 zeros to 19, but closer to 5 to 2, i.e. the differences are huge.

If length is a concern, 12 lower + upper characters is 3e20. Other big companies still force people to use minimum 8-length with special characters. Why force people to use special characters - and to an extension numbers - when another 2 characters is not only more secure but far easier to remember? Why are they so anal about this?

Some people argue that long-length passwords are bad because people just use real words so that limits entropy greatly. To that I would say same thing with shorter passwords, hence dictionary + rule attacks. Forcing numbers and/or special characters just results in passwords like [word]1!, or worse, Password1!. Can someone explain either why special characters are a necessity in secure passwords or why it is considered that way despite evidence against it.

It's UX.  Requiring mixed characters makes it less likely for a user to use a common word or phrase, which would make it highly susceptible to a dictionary attack.  The additional entropy is a bonus; as you point out, additional characters would be just as effective.


SQL injection with a URL separated with dashes I have have used sqlmap for a long time now. I have come across a this url pattern. http://www.example.com/parameter-somethingid01-anotherthingid023

Where parameter is expendable meaning it doesn't matter if the it's available or not.
http://www.example.com/somethingid01-anotherthingid023 is the same as the one above

if you change somethingid01 to somethingid012 or other id it will take you to a different resource that applies to anotherthingid too.

My question is how am I going to tell sqlmap to attack this kind of URL?

As described in the sqlmap manual on the sqlmap GitHub page (https://github.com/sqlmapproject/sqlmap/wiki/Usage#uri-injection-point) you can insert an asterix at the spot where sqlmap should inject the payloads if that spot is in the URI.

That means:
If you want sqlmap to replace somethingid01 with the payload you would give your url like:

sqlmap -u "http://www.example.com/*-anotherthingid023"

If you want sqlmap to scan both parameters you have to replace the second one as well:

sqlmap -u "http://www.example.com/*-*"


Can information security risks essentially only be triaged according to the CIA triangle? Can information security risks essentially only be triaged according to the CIA triangle (Confidentiality, Integrity and Availability) or are there other possibilities?

There are lots of other possibilities.
Note that the CIA triad is not so much a model for security risks as it is for security goals/objectives. It has often been criticized for being overly simplistic and incomplete. Consequently, there are lots of alternative models and extensions of the CIA triad. One popular option is the Parkerian hexad that consists of confidentiality, possession, integrity, authenticity, availability and utility. Others have suggested extending it with authenticity and non-repudiation to the CIAAN model.

If your primary goal is threat risk modeling, there are other models to consider - which can still be associated with the CIA triad. For example, there is the STRIDE model which classifies threats via the categories spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. Here is how it relates to CIA:

STRIDE is what an attacker can do. TID is the attack version of CIA:

Defenders want Confidentiality – attackers use Information Disclosure
Defenders want Integrity – attackers use Tampering
Defenders want Availability – attackers use Denial of Service.

But, what about Spoofing, Repudiation and Elevation of Privilege? Enter the (modern) non-linear attack:

Spoofing and Elevation of Privilege are the entry points to pry open the doors.
Repudiation is covering the adversary’s tracks during the initial compromise and the breach.

(Source)


Invalidate API tokens when LDAP user is invalid I'm using oauth2 and LDAP for authorization and authentication of an API. Authentication flow is given below.

User sends LDAP username and password (with password grand type) to
the server.
Server validates the password communicating with the LDAP server If valid, server returns an access token and a refresh token.

User keeps accessing APIs with access token until expired. When expired, the refresh token can be used to get a new access token and a new refresh token. The user can keep accessing the APIs forever updating the tokens.

Another requirement is making tokens invalid when user password is changed or when the user is disabled in the LDAP server. Is there anyway to do this?

So far I tried following approach:

Store the LDAP password hash in the server when initially user sends them.
When refreshing the token, fetch password hash of the user from the LDAP server and compare them to the one saved in the server.
But it looks like it's not always possible to fetch the hash. It depends on the LDAP configuration,directory and Permissions

I've got an idea how to solve this situation not ideally, but it could work.
It's kind of hacky.
If your LDAP server is OpenLDAP (I'm not so familiar with other servers like 389, opendj or active directory), You can enable accesslog overlay, and search for changes in entries.

So with query in base cn=acceslog like this:

"(&(reqType=modify)(reqStart>=YYYYMMDDhhmmssZ)(|(reqMod=userPassword*)(reqMod=isDisabledAttribute:=disabledFlag))))"

where

reqType is filtering operation which would be modify
reqStart is last time you've checked (f.e.: every minute)
reqMod with userPassword filtering password changes
isDisabledAttribute - attribute with deciedes whether the user entry is disabled

requiring reqDN will return users DN - then you can get any attribute from his file and invalidate his token in the token storage - I belive you're able to pair it to some attribute form user entry.


Why is PHPs $_REQUEST considered to be evil? According to the OWASP PHP cheat sheet:

  Using $_REQUEST is strongly discouraged. This super global is not recommended since it includes not only POST and GET data, but also the cookies sent by the request. All of this data is combined into one array, making it almost impossible to determine the source of the data. This can lead to confusion and makes your code prone to mistakes, which could lead to security problems.

I understand why this is bad practice from a programming perspective, but I do not understand the security implications of this. Since the attacker - the person sending the request - has full control over all three - get variables, post variables and cookies - I don't see what difference it makes.

One issue I could see is if e.g. a WAF checks the query string for suspicious behaviour, so the attacker instead delivers the payload in a cookie. But is there any other issues? Can anyone give me a concrete example of how the usage of $_REQUEST would cause a vulnerability?

This is because it widens the scope of reflective XSS to POST requests, as most scripts don't check the HTTP verb explicitly.

Imagine you've got the following code in a script that usually expects a POST request:

<?php
if (($order = $orders->fetch($_REQUEST['id'])) === FALSE)
{
    die('Could not find order number ' . $_REQUEST['id']);
}
...

If $_POST were used, the XSS vulnerability would still exist, but it could only be triggered by a user going to an attacker-controlled page first so that a form could send the exploit via POST. Instead, the attacker only needs to get the victim to click a link such as:

http://example.com/vulnerable.php?id=<script>alert(document.cookie);</script>

It's also a concern for other verb-confusion attacks, where two parts of the script make separate judgements on the verb being used (e.g. one assumes it's a GET, the other a POST) resulting in unexpected behaviour.


Why is it possible to verify RedPhone inline while not OTR text apps? Using RedPhone (the right way), one would call, establish a connection and read off the text verification on screen to the other party. If they match, it's ZRTP-secure, if it doesn't it's MITM'd.

Why can we do that on RedPhone, while not, say, on ChatSecure, Telegram, or Wickr? Why do we have to use OTHER means to verify the identity?

Also, is it ok to verify the identity in an UNSECURE media for the second case? Like using WhatsApp to verify Wickr identity?!

Reading off the text verifies that you have a secure connection to the person that read off the text. How do you know that's the person you intended to communicate with? ZRTP essentially assumes that you know by recognising their voice.

https://silentcircle.com/faq-zrtp#20

https://silentcircle.com/faq-zrtp#26

OTR obviously can't make that assumption, so you have to establish their identity some other way. If you use the fingerprint method, you don't need a private channel, just a verifiable one. For example, if you know the person's voice, you could make a phone call and exchange fingerprints.

For the other methods, you need to establish a shared secret using an already secure channel.

(Disclaimer: I've never used RedPhone, Telegram, or Wickr, but I'm assuming they are similar to other ZRTP and OTR apps).


Generate Fake Encrypted Data I want to create a file server that will be serving encrypted files without permissions. It would be really awesome if it were impossible for a hacker to tell if a file exists or not, so I am thinking that if every endpoint that does not contain real data returns a file that appears to be valid encrypted data it would be impossible to tell which data is real and which is fake.

What is the problem with this approach?

Look Into the world of honeypots. You can generate fake machines, printers, network traffic ect. The goal is to direct the intruder to the fake network which is usually on a DMZ, different subnet or separate firewall while the IDS kicks into action.

You also download a script based random text generator and then apply whichever encryption method like MD5 to the string and then pipe that to a txt file followed by compressing it. I like the “bullsh*t” text generator the best.


Why only script-src unsafe-inline is reported as a high severity finding? I'm evaluating a CSP policy using https://csp-evaluator.withgoogle.com/. The policy is configured as follow:
default-src 'self';object-src 'self';script-src 'self' 'unsafe-inline' 'unsafe-eval';script-src-elem 'self' 'unsafe-inline' 'unsafe-eval';script-src-attr 'self' 'unsafe-inline';

Why only 'unsafe-inline' of 'script-src' is reported as a high severity finding? From what I understood also 'script-src-elem' 'unsafe-inline' could be dangerous. What am I missing?

I don't think you are missing anything, this does seem to be an error in googles CSP evaluator.
script-src-elem is used to control the source of script tags (inline or external; see also the spec). You can test this yourself, eg with:
<?php
header("content-security-policy: script-src 'self'; script-src-elem 'self' 'unsafe-inline'")
?>
<script>alert(1);</script>

Viewed with Chrome, the payload will fire (Firefox does not support script-src-elem). If you remove unsafe-inline, the CSP will block the script.
So we can see that script-src-elem 'unsafe-inline' is indeed dangerous.


Is auto-redirecting to another site a secure defense against POODLE? Normally, servers that support SSL 3.0 are vulnerable to the POODLE attack.  But, consider a server that has the following interesting combination of features:

It supports SSL 3.0.
If you connect to it via SSL 3.0, the connection succeeds but it immediately returns a HTTP 302 redirect to a web page on a different host suggesting that you upgrade your browser to a more modern version.  Any attempt to connect via SSL 3.0 triggers this auto-redirect; it will never return any content or do anything else.

Is this secure?  Or is this also vulnerable to POODLE?

I am suspicious that this might be vulnerable to POODLE.  From my understanding of the POODLE attack, the attack only relies on watching whether the server accepts or rejects some particular modified ciphertext.  (What the server does after that -- e.g., sending a redirect -- seems irrelevant to the POODLE attack.)  However, I'm not sure if I understand all the details.  So, is this an effective defense against POODLE?

I do realize the typical advice is to disable SSL 3.0.  So, just to be clear: I'm not asking whether you'd encourage me to configure my own server like this; I just want to know if a server that works like described above is secure or insecure.  And I suspect there might be a reason why someone would do this: it ensures that IE6 users see a web page asking them to upgrade to a more modern browser, rather than just blocking IE6 entirely.  I know about TLS_FALLBACK_SCSV, but my question remains valid for clients that don't support it.  So, is this redirect thing an effective defense against POODLE?

This can probably be made safe, if some additional protections are added.  POODLE can not be used to intercept an existing connection or to man-in-the-middle a future connection. Instead this attack only manages to slowly obtain more information about the encrypted data.

You will need to add an additional defense: any secrets sent over a SSL 3.0 need to be immediately invalidated.  For instance, if a session cookie is received over a SSL 3.0 connection, invalidate that cookie.

With this addition, this can probably be made safe.  Clients that only support SSL 3.0 will be safe, because all of their connections will be redirected, so these clients never get to see any sensitive information and the attacker will never be able to get a valid session cookie or similar sensitive data. Thus even if the attack would succeed it could not get any useful data back because no useful data gets exchanged.  For clients that support both SSL 3.0 and SSL TLS 1.x, the additional defense should stop POODLE attacks.  Since POODLE requires lots of attempts (new connections), immediately invalidating any session cookie sent within a SSL 3.0 connection should prevent a POODLE attacker from learning the session cookie.

Without this additional defense, just redirecting is probably not safe.


Can product keys harm computer? I downloaded Windows from Microsoft website. Then I type in (or paste) a product key that I bought from an unofficial seller to activate Windows. Can that lead to any security issues?

No, the product key has nothing to do with the security part of the OS.

If you do not activate a Windows 10 copy, the only practical inconvenient is that you cannot make desktop-related background customization. Everything else work exactly the same.

As for a key brought at a discount, it may very well work and let you activate and use your product on unlimited time or stop working later. In both cases, there no influence on the security part.

But that being said, you should note that owning a product key that works does not mean your software is licensed. The fact that MS does not care is another matter.


Should CSRF 'Double Submit Cookie' technique have a different seed value for the cookie versus the HTTP POST? I'm reading about the OWASP double submit cookies method of protection and there it states that the cookie value between the header and form should match.

That seems to be somewhat of a risk, as the article states, as the value embedded in the form can be accessed by the DOM & Javascript.

Would it not be more secure to have a differently seeded value for the cookie and the HTTP POST embedded value, so that a malicious script can't infer the cookie value

ASP.NET's AntiForgeryToken is an example of a double submit cookie.  Its unclear to me if that token uses the same value for the cookie as the form.

A few points of note:

Don't use double-submit cookies, as you said and as the article states, this not very secure, and opens you up to other attacks.
"a differently seeded value for the cookie and the HTTP POST embedded value" - Yes, this approach is much preferred, but this is not a double-submit cookie - you are referring to what is known as a Form Token.
Using form tokens used to be more problematic, since it was difficult to get it right and avoid the subtle errors which invalidate the solution. Nowadays, there are very good packages out there that do this for you, such as OWASP's CSRFGuard. Similar mechanisms are also built into many frameworks, including ASP.NET.
As I mentioned, ASP.NET's AntiForgeryToken (actually, that's ASP.NET MVC...) is based on form tokens, and not double-submit cookies. Which, as mentioned, is not secure.
ASP.NET itself also includes protection based on ViewState, when using UserKey attribute.
Many other modern frameworks also have some builtin protection, including Spring, RoR, etc.
Another alternative, which might or might not be relevant, is re-authentication of the user, for specific actions. E.g. before transferring a large some of money to a 3rd party from your bank account, or authorizing connections in LinkedIn.
Don't use double-submit cookies.


How does OS detection work in practice? I was wondering how OS detection really works on Nmap. I know it is about to send different tcp probes to see how the target machine responds to them.

But what kind of probes would distinguish a Linux system or a Windows system? A Linux 2.4 or 2.6 system? Windows XP or Windows 7 system etc?

you can check the following links  NMap OS Detection
 and Paper About Nmap Detection
you will find on them different methods used for OS detection By Fyodor the Creator of Nmap and if you want to dig dive you can purchase his book from amazon.

From NMap OS Detection:

  ...dozens of tests such as TCP ISN sampling, TCP options support and
  ordering, IP ID sampling, and the initial window size check, Nmap
  compares the results to its nmap-os-db database of more than 2,600
  known OS fingerprints and prints out the OS details if there is a
  match


Will a crossdomain.xml file reduce a potential security risk? I maintain a website were users are allowed to upload files. I'm doing already some good MIME-checks, consistency checks, virus checks, blacklist checks based on hash lists, some other custom checks and also I used most of the best-practices around the file upload functionality. But I was thinking about the following worst-case scenario:

Let's say a user will succeed in uploading a SWF file and will be able to access it from my domain and execute it in a browser. Could I isolate or reduce the risks by adding a strict crossdomain.xml file already? Just to prevent escalation in this scenario.

My site is currently not using any flash or silverlight and for that reason I suppose I don't need a crossdomain.xml file. Nevertheless, I'm wondering if I do good to setup a strict configured crossdomain.xml file in case a user will be able to upload and execute malicious code (for example using flash).

I would love to hear some opinions about this! Thanks in advance!

I think that you are asking if you need to protect yourself in case the impossible (or at least highly unlikely) occurs.

I believe that a crossdomain.xml is only involved when a client is directed to load content from the non-originating server. So adding a strict crossdomain.xml file will protect you against that.

But the crossdomain.xml won't protect you from a user directly accessing the SWF file from your server as there's no second-domain involved in that scenario.

If you haven't disabled downloading of SWF files in your web server, I would do that first. Details will depend on the web server your using but it shouldn't be hard to do.

Once you've already disabled both uploading and downloading of SWF files, I guess the crossdomain.xml will help protect against certain attacks but far from all. So I see no harm but I don't see a great gain either.

Hope this helps.


How to protect against "padding oracle attacks." I need to encrypt something on my server and save the result. Since I am not a security expert, I want to implement as much existing code as possible.

I found a fully build function on php.net but it says that "is not protected against padding oracle attacks."

What are "padding oracle attacks" and what should I do about it?

The padding oracle is a mixture of a protocol flaw and an implementation flaw. Namely, a "padding oracle" leaks some information about secret data through how it reacts to maliciously crafted invalid input. A good protocol will first validate the input data through a MAC before considering decryption and its corollary, padding processing. That's what the "encrypt-then-MAC" construction is about. A bad protocol will do things in the wrong order, and may suffer from leakage by applying decryption first; that's what happens in SSL with CBC encryption modes.

If the protocol is bad, then the implementation must be specially shielded against the kind of invalid messages that attackers will try to handcraft in order to turn some implementation (e.g. a server) into a padding oracle. Such shielding is hard (e.g. the Lucky Thirteen attack demonstrates, in lab conditions, the theoretical possibility of leakage even with thoroughly shielded implementations).

The PHP function you link too is only about encryption; by definition, it cannot do anything against padding oracles. Protection against padding oracles is more at the protocol level. As is typical with PHP, dangerous functionality is provided with little warning, and a suboptimal API.

Designing your own secure protocol is even harder than shielding against side-channel attacks, so don't do that. And even if you do, don't do that in PHP.


Unusual Google Chrome Download Redirection When I go to https://www.google.com/chrome/, I get redirected to sign in and then forwarded to some app engine link as can be seen in the continue parameter of the following URL:
https[:]//accounts[.]google[.]com/ServiceLogin/webreauth?service=ah&passive=true&continue=https%3A%2F%2Fuc.appengine[.]google[.]com%2F_ah%2Fconflogin%3Fcontinue%3Dhttps%3A%2F%2Fchr-183746449-dot-googwebreview[.]appspot[.]com%2Fchrome%2Fbrowser-tools%2F%253Fxpv%253D1&flowName=GlifWebSignIn&flowEntry=ServiceLogin.

(Please don't click the link unless you know what you are doing, as it is potentially suspicious.)
I tried to sign in with a test account to see where it goes, and eventually ends up at the following link:
https[:]//chr-183746449-dot-googwebreview[.]appspot[.]com/chrome/browser-features/?xpv=2

(Please don't click the link unless you know what you are doing, as it is potentially suspicious.)
I recommend no one click on the suspicious links, but I am just trying to see if anyone has encountered this issue and / or knows why it happens. (I have removed the hyperlinks so no-one accidentally clicks them.)
I examined it on VirusTotal as well but could not find much more info and it doesn't trigger any engines:
https://www.virustotal.com/gui/url/7b7d19079d611b1c17c05968ba3fd0b1c3c79b9ed83c19657ef9450fe615c577/detection

Clearing my cache on my machine corrects the problem and I am able to get to the correct page when going to https://www.google.com/chrome/. However, I tested some time later and it seemed to happen again. Since it is only happening on this machine on my network and not others I am wondering if the cache on it is somehow getting poisoned, and if so how. It is an M1 Mac mini if it is of any relevance.
I also reset the wifi-gateway and password but was able to reproduce it on that same machine after sometime. This was also after I had completely re-formatted the hard drive and had done a complete re-install of the OS from the recovery partition. The problem seems to reoccur again maybe about 30 minutes after clearing the cache. Also if I try to visit the link multiple times quickly, about 50% of the times I will actually end up on the correct Google Chrome download page, and the rest of the times I will be redirected to:
https[:]//accounts[.]google[.]com/ServiceLogin/webreauth?service=ah&passive=true&continue=https%3A%2F%2Fuc.appengine[.]google[.]com%2F_ah%2Fconflogin%3Fcontinue%3Dhttps%3A%2F%2Fchr-183746449-dot-googwebreview[.]appspot[.]com%2Fchrome%2Fbrowser-tools%2F%253Fxpv%253D1&flowName=GlifWebSignIn&flowEntry=ServiceLogin.

This was encountered using Safari on MacOS Big Sur 11.2.3. The other odd thing is that it says that (google.com/chrome) is the referrer for:
https[:]//accounts[.]google[.]com/ServiceLogin/webreauth?service=ah&passive=true&continue=https%3A%2F%2Fuc.appengine[.]google[.]com%2F_ah%2Fconflogin%3Fcontinue%3Dhttps%3A%2F%2Fchr-183746449-dot-googwebreview[.]appspot[.]com%2Fchrome%2Fbrowser-tools%2F%253Fxpv%253D1&flowName=GlifWebSignIn&flowEntry=ServiceLogin

when I check the web requests in dev tools. However, if I use private browsing on Safari this issue does not happen, and it goes to the correct Google Chrome Download page: https://www.google.com/chrome.
I would really appreciate if anyone can shed any insight, because I am kind of worried why this is happening and if this machine and / or my network is potentially compromised.

I assume this URL re-direction activity as suspicious (Phishing) due to the below reasons. You can visit this site to know more details.

Google never requires sign-in to download chrome binary.
https[:]//chr-183746449-dot-googwebreview[.]appspot[.]com is not an official Google site but a random site hosted in appspot with SSL(GCP domin) which mostly requires Gmail authentication to access (through Firebase).
Your final URL pretend to show Chrome browser features page but the actual site is https://www.google.com/chrome/browser-features/.
Anyone can deploy a random application in Google Cloud with unique hostname having domain xxxxx[.]appspot[.]com so your specific URL is not shown as suspicious in Virustotal.

As stated in the comments, many users are facing such re-direction so nothing to worry about your specific system or internet. This might be a local cache / DNS configuration issue and you may report it to chromium team.


Can BadUsb only be delivered via USB? BadUsb works by infecting a computer when plugged into the USB port.  Is it also possible for an attacker who gains control of a system, such as remote access, to then infect any connected USB devices?  Or does it only affect the ports it's plugged into?

If a USB stick accepts unsigned firmware updates then yes it's vulnerable to a bad USB attack.  There are products out there that only accept digitally signed firmware updates.  These devices are not susceptible.
http://www.ironkey.com/en-US/solutions/protect-against-badusb.html


Trace wireless connections in airplane mode I was wondering if turning on Airplane Mode really disables all wireless connections.

If so, anything you do on the phone locally can not be traced, seen, or viewed, hacked, etc. by anyone over a network. Correct?

That is I can privately work locally without a network state, data submitted via programs through the web, etc.

Yes, “airplane mode” disables all methods through which the device voluntarily transmits information over wireless networks. That's the point.

The device is still emitting, of course. For example it emits visible light: all information that is displayed on the screen can be snooped by shoulder surfing or hidden cameras.

Even information that is not voluntarily emitted can sometimes be snooped. Whenever a variable current is sent over a wire, this creates an electromagnetic field; in principle, extremely precise measurements could reconstruct the data traveling on each wire. In practice, this kind of snooping is fairly easy for CRT displays (which emit a lot of radiation) and requires mildly expensive equipment for LCD. For anything smaller, it is all but impossible to discriminate between the many buses, or at least far more expensive than hiring a goon with a monkey wrench. This still leaves radiation as a side channel, but to exploit it, you really have to know what you're looking for.

For all practical purposes, a device in airplane mode used in a situation where no shoulder surfing is possible is immune to eavesdropping.

Note that if malware is present on the device, all bets are off. Malware could pretend that the device is in airplane mode when it isn't, or more simply, record data to send later.


Is it posible to bypass BIOS password without owner knowing later on? My laptop BIOS is password protected. Probably the password can be bypassed using some hardware and software means. But is it possible that somebody having access to laptop but not knowing the password can bypass it without me knowing it when I log on at a later stage ?
I am trying to protect my laptop from malware / spyware. I am concerned about spying. Since important folders are encrypted, I am not worried about data theft. Attacker may have 10-12 hours of time.

Yes it's possible.

BIOS passwords are not usually taken seriously by manufacturers as a meaningful security measure on their own, since most people don't take care to secure their systems physically. Instead it's expected to act as a deterrent in cases where physical accessibility is reduced, such as public access terminals in schools or offices, to prevent users from tampering with settings that could case maintainers a headache.

if an attacker can get hold of your device he could apply hardware debugging techniques to extract your current password, or as is much more likely, install a keylogger and wait for you to enter the password for him.

If you want to secure your device against attackers bypassing the BIOS password, you should lock it away in a tamper proof hard case, which will allow you to determine if an attacker has had physical access to the device.


Finding original command result from MD5 hash Basically I hashed the result of the "date" command with md5sum:

$date | md5sum

The output is indeed in the likes of:

e4c94362cd4fd71ec6aca78c7411bdc3  -

My question was: is it possible to recover the result of the date command knowing the date pattern (except for maybe the minutes and seconds)?

I tried using john's mask option as well as a custom wordlist, without result.

Do you guys have any idea how we could pull that off?

The key aspect of hash functions that make them so useful is that they are one-way - it is very easy to hash an input and produce an output, but very difficult to convert a given output into a valid input. In other words, (in most cases) the best way to figure out what input was used to generate a given output is to guess-and-check.

The good news for you is that this can be automated, and MD5 is pretty fast - so you can guess-and-check many, many possible inputs.

Let's say you have an input in the format of "yyyy-MM-dd hh:mm:ss", and you know the date component (but not the time, so "2019-12-10 ??:??:??"). There are only ~85k possible  distinct time values to check, so if you simply enumerate through all the possible values until you get a match, you'll only have to run an average of ~42k hashes. For single pass MD5, most modern systems will be able to run this in a fraction of a second.

So, while there's no way to reverse the hash, in this instance brute-forcing it is not all that compute intensive.


Torrent sites on the onion network being served over http I've noticed that torrent websites like the Pirate Bay are served over http.
This means that when using a network like the Tor onion network, where the first server in the response chain receives the website unencrypted, could they not change the links on the website? Let's say that a node is compromised, or run by a hostile owner.
http request -> onion network -> server
http response -> server 1 (s1) -> s2 -> s3 -> client

If server 1 is compromised, can it alter the data?

Tor is a (multi layer) encrypted tunnel. If the endpoint server (here PirateBay) is an Onion server (the URL ends by *.onion), Server 1 see an encrypted response. The Tor software on the client machine decrypt it into plain HTTP.
Server 1, 2 and 3 can alter the encrypted data, but without knowing its content. Also, this data will be rejected by the Tor client because it will detect a corruption.
If the endpoint server is a classical web server (with a URL like piratebay.org), then Server 1 can see the plaintext data of the requests and alter them.


What is DVNC and how does it work? As stated on their website:

  DVNC is not encryption but is a new branch of cryptography and
  information science. DVNC employs a new paradigm in secret keeping to
  keep your data secured.

I understand it is used like traditional cryptography to protect a message from being understood by an attacker, even if it is intercepted.

However, I've went through their presentation and I don't understand what it is exactly and how it works. Can someone explain to me ?

The DVNC whitepaper is heavy on analogies and buzzwords, light on content, and the source code is in a format I can't view, but as far as I can tell, the "key advances" of DVNC are as follows:

The cyphertext alphabet can be much larger than the plaintext alphabet.
The cyphertext alphabet can use a totally different set of symbols than the plaintext alphabet.

In short, they appear to have re-discovered some of the great advances of 17th-century cryptography.


Strange Event Log Entry - Windows Server 2008 Reviewing some logs recently, and came across a strange failure in our Windows 2008 DC.

An account failed to log on.

Subject:
        Security ID:            NULL SID
        Account Name:           -
        Account Domain:         -
        Logon ID:               0x0

Logon Type:                     3

Account For Which Logon Failed:
        Security ID:            NULL SID
        Account Name:           @
        Account Domain:

Failure Information:
        Failure Reason:         Unknown user name or bad password.
        Status:                 0xc000006d
        Sub Status:             0xc0000064

Process Information:
        Caller Process ID:      0x0
        Caller Process Name:    -

Network Information:
        Workstation Name:       <REDACTED>
        Source Network Address: <REDACTED>
        Source Port:            4102

Any idea what this is?

This was an EventID of 4625, other failures nearby were another 4625 and a 4776.

Background: Redundant domain controllers, small LAN, some legacy software applications that might use older auth methods on the domain.  Win Server 2008, Win XP SP3.

0xc0000064 means that the user name in the logon attempt did not match a known account.  That would be the "Unknown user name" part of "Unknown user name or bad password". ;)


Policy requirements of Sarbanes-Oxley (SOX) I'm hoping this question will be appropriate for this site.  The ServerFault people didn't think it applied to system administrators.  Certainly I think it can be answered from a security perspective, if nothing else.

Ever since the passage of Sarbanes-Oxley (SOX), IT departments around the US have used "SOX compliance" as an extremely broad reason for implementing all sorts of policies.

The thing is, as I understand it, there's not one-single mention of IT in the SOX act.

I've had IT departments tell me they are unable to ship a replacement laptop to my home address because it's not permitted by SOX. I've been told I'm unable to have root access on a Unix server because of SOX. I've been told a company was unable to use git or mysql because of SOX and had to use ClearCase and Oracle instead.

Has anyone experienced this? More importantly, does anyone have any definitive information on the restrictions which SOX would impose? I know it requires truthful, accurate and timely financial reporting and certification by corporate executives, but beyond some tight controls of the financial systems, I fail to see why it should apply to general servers, code repositories or user laptops.

What are reasonable SOX policies?

Any thoughts appreciated.

See Does (J-)SOX Forbid the Use of Open Source Software?. Excerpt from my answer there:

  Fact is that throwing extra unnecessary requirements onto yourself and claiming they're regulatory doesn't earn you any brownie points, it just costs you more.

Overstatement of the bounds of SOX is common and wrong. Now, it may somehow be the case that your code is material to the company's annual financial statement and they don't want to add another system to the realm of audit, but that's probably not the case.

SOX means that root on the machine which houses the company's financials is closely guarded, but it generally doesn't have any connection to most people's workstationns. The reason that there is so much  madness surrounding SOX is because the law doesn't spell it out. The SEC provides "guidance", but interpretation has been pretty scattered.

SEC guidance from 2007 is a good pointer and reminder that if what you're talking about doesn't relate to the internal controls over financial reporting, it's not relevant to SOX.  Thus, changing passwords every 90 days can fall under SOX (e.g., accountants authenticate to the ledger system using domain accounts), but shipping a replacement laptop to home as opposed to having you come in and take it off your desk doesn't matter.

Further, the SEC encourages companies to review controls based on risk

  The Interpretive Guidance reiterates the Commission’s position that
  management should bring its own experience and informed judgment to bear in order to
  design an evaluation process that meets the needs of its company and that provides a
  reasonable basis for its annual assessment of whether ICFR is effective.  This allows
  management sufficient and appropriate flexibility to design such an evaluation process.
  Smaller public companies, which generally have less complex internal control systems
  than larger public companies, can use this guidance to scale and tailor their evaluation
  methods and procedures to fit their own facts and circumstances.  We encourage smaller
  public companies  to take advantage of the flexibility and scalability to conduct an
  evaluation of ICFR that is both efficient and effective at identifying material weaknesses.

Thus, think about the impact your application could have on the company's financial reporting. Not financial growth, profit, or anything else -- just the reporting. If it's not related (an easy test is "does it ever deal with dollars and cents?"), then somebody is leading somebody else astray. Perhaps you can point this out to them, or perhaps somebody is lying because it makes it easier for them to tell you want they want to say and there's nothing they can do about it.


What are vendor affirmed algorithms in FIPS 140-2 FIPS 140-2 allows FIPS approved algorithms to be either tested by CAVP or to be vendor affirmed. What does "vendor affirmed" imply here? Can I say my AES implementation as vendor affirmed and get it added to the FIPS certificate?

This is a bit of a guess, but on page 6 of the Derived Test Requirements for
FIPS PUB 140-2, we have (emphasis mine):

Required Vendor Information
VE01.12.01: The vendor shall provide a validation certificate for all Approved cryptographic algorithms.
VE01.12.02: The vendor shall provide a list of all non-Approved security functions.
VE01.12.03: The vendor shall provide a list of all vendor affirmed security methods.
VE01.12.04: The vendor provided nonproprietary security policy shall include reference to all vendor affirmed security methods.

It sounds like, during a certification, they're breaking crypto implementations into 3 categories:

Approved cryptographic algorithms: implementations that have already been certified (that you use internally). These will be excluded from the review.
non-Approved security functions: if you really want to use MD5 or twofish, or some other non-FIPS crypto, you need to declare it. These will be excluded from the review.
vendor affirmed security methods: things that the vendor claims conform to the spec, but have not yet been verified by NIST. Presumably this is what you are submitting for testing.

So as for your question:

Can I say my AES implementation as vendor affirmed and get it added to the FIPS certificate?

Of course! You are perfectly welcome to run your AES implementation through the CAVP and get it FIPS certified (if it passes, of course)


password complexity and policies from the users' point of view There are two sides of password complexity, the administrator's side and the users' side. They are effectively disjointed requirements. Good complexity and policies of passwords are discussed often. But I have not seen any good guides or best practices for the users. All that is available are always those administrator's point of view best practices: Make a random complex long password and change it every other day...

In the end, the more complex requirements and policies are the more users will try to circumvent them by making simple passwords, writing them down, etc. but it is not their data they want to protect and ultimately, once the security is breached, you don't get your losses back.

I have been in both situations, as an administrator and now as a user who is forced into zero password history, full complexity and change every 60 days. Plus I have my other 10 complex passwords to remember. So I started using simple alphanumerical sequences  like: pou987^ or opqR678(. I know it is bad, but what the hell, my brain is limited and getting old.

Is there a good guide to construct non-random passwords that take into account zero history that can be remembered?
(I do not need the password to be ultra strong, I know it cannot be done, but there are other barriers in place, firewalls, limited number of password attempts, physical access restriction, so I want the password to be considered strong with these extra barriers in place.)

What should I suggest to my users, as an administrator? How should they approach the password creation (sorry but NOBODY in the company is going to remember things like gZ9]Rjm}t5d? which is now still considered weak and strong passwords start at 16 characters, that is idiotic)?

There are now very good guidance for policies that are foundationally good for users. Most of the requirements you state in your question are now antiquated.

Best: use a password manager! Let software generate and enter the password for the user. No memory required and the password can be generated at maximum complexity (entropy/randomness, whatever you use to understand password strength)

But if you need to generate your own passwords:

First: stop requiring that users change their passwords so frequently. Most guidance suggests never requiring a change until there is a specified need to change (as in never, except when the account is suspected of being compromised). There is some debate on this point, but some admins only go so far as requiring an annual change.

Second: there has been encouragement for a long time to stop using the term "password" and using the term "passphrase". Length is far "stronger" than complexity. So, create a sentence: Word word word word. There's upper, lower, and special characters (space and a period). Is this perfect? Absolutely not! Is it strong "enough" and user-friendly? Yes, for most use cases. Admins and senior execs should be using far better passwords (see password managers above).

Third: [this is where the community will skewer me] require Two Factor Authentication and if used, relax the length and complexity requirements. I had never thought about this until I taught security awareness to Special Needs teachers who came up with this idea during class. It can be difficult for some differently abled and the very young to enter a complex or long password. If 2FA is implemented correctly, the password can be very simple, and yet secured by 2FA. Even if someone else needs to enter the password for the user, the 2FA token leaves with the user. Even if you do not loosen the complexity requirements, use 2FA everywhere you can.

All these things (except relaxing password complexity if 2FA is used) have been commonplace password guidance around the world for a couple years:

UK:
https://www.ncsc.gov.uk/guidance/password-guidance-simplifying-your-approach

USA:
https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-rules-what-you-need-to-know/

Microsoft:
https://www.semperis.com/microsoft-upends-traditional-password-recommendations-with-significant-new-guidance/


Does ASP.NET Viewstate implicitly prevent CSRF attacks? What does this mean for MVC? If an encrypted ASP.NET Viewstate is submitted with every form, and control POST, does that mean that ASP.NET is less vulnerable to CSRF than other solutions with this?

What is the extent and limitation of that protection?

Since the AntiForgeryToken isn't implemented by default in ASP.NET MVC does that mean that those sites may be more likely to be at risk?

The purpose of ASP.NET ViewState is to persist control state between post-backs (see MDSN explanation), it does not implicitly enable security that would prevent CSRF.

Also note that encrypted ViewState in unpatched older versions of ASP.NET are susceptible to an encryption vulnerability.

To enable this type of protection you could:

Use ViewStateUserKey (See
a high level description of the feature, the MSDN docs for ViewStateUserKey and the OWASP CSRF prevention cheat sheet.
Use a custom method to render a custom managed hidden field (per transaction) in the form and check for it with each client request.
Use a third party library dedicated to CSRF such as AntiCSRF.

ASP.NET MVC3 does have an anti-forgery token that is used with the [ValidateAntiForgeryToken] attribute on the controller action (See http://msdn.microsoft.com/en-us/library/system.web.mvc.validateantiforgerytokenattribute.aspx). In the view’s form tag call the Html.AntiForgeryToken helper (See http://msdn.microsoft.com/en-us/library/dd470175.aspx) with following syntax:

Web Forms:

<%= Html.AntiForgeryToken() %>

Razor:

@Html.AntiForgeryToken()


Making PII worthless I've had a thought rolling around in my head for the past few years about Personally Identifiable Information or PII.

Identity theft is a big business* for the bad guys. They make tons of money off the back of poor schmucks who either inadvertently give them their information (through social engineering or what have you), some sort of data spill (someone accidentally discloses the information), or through outright theft (hacking). Once the bad guys get the information, they can use it to set up fake accounts or what have you and cause all sorts of problems for just about anyone.

My thinking has been, the easiest way to combat this would be to make this kind of information worthless to anyone. I suppose it would take a complete change in the industry. My questions are:

Has anyone been working towards this end?
Could PII become worthless to data thieves?
If so, what is being done and what might replace PII?

EDIT:

*The Washington Post reported identity theft was a $15.4 Billion financial loss in 2014.

PII is what defines an individual, and not only something that can be subject to identity theft and dark web transactions.
PII includes identifiers such as social security numbers, name, address, date of birth, personal preferences, religious beliefs, finger prints, you name it. Again, everything that defines you as an individual. https://en.wikipedia.org/wiki/Personally_identifiable_information

So you can't replace PII, as long as there are individuals there will be PII. And as long as there are individuals, there will always be at least one person who cares about PII (i.e. his or her own) and values it greatly.

-- EDIT to address "what is being done" ----

There are some startups working on the idea that the individual controls his PII from a central dashboard. The idea is that any organization that wants to use those PII needs to be specifically authorized by the individual.
Ideally any service providers that call on the data would never copy it and save elsewhere, but I am not sure how you could manage that from a technical stand point.

I have seen interesting implementations with a specific health care aspect: users centrally manage health care data and can control who has or no longer has access to, or consent for, using PII of the individual.


Smartphone / GSM Sniffer This question would be in the category of SmartPhone Sniffers.

So we have sniffers that can show the packets that are being sent across a wired or wireless (802.11) network. I am just performing a basic research on GSM Sniffers and I would like to know if there are tools available for monitoring the space for specific frequency ranges and capturing data..

What would be the complexity of designing such a tool?

The hardware tool that is suited to his is the Universal Software Radio Peripheral (vendor site). You can get a leg up on decoding the transmissions by looking at the work done for the OpenBTS system. So, hardware-wise it's commodity equipment, though a few thousand dollars because it's not very common. Software wise, the groundwork is already there to pull from.

Cellular data is typically encrypted between handset and tower, and so far most attacks against that have ben active. Thus, complexity of sniffing usable data may be relatively high / a research project.


Can we detect risk signals or potential vulnerabilities in git meta-data? I'm wondering whether git commit metadata can shred light on potential risk signals or vulnerabilities.
Henry Hinnefeld has investigated this, here but this seems to be a way of detecting vulnerabilities which already have been spotted by other developers.
Can anyone think how metadata alone can detect vulnerabilities that have never been found before?

... but this seems to be a way of detecting vulnerabilities which already have been spotted by other developers.

This is the wrong interpretation of what he did. He tried to create a machine learning model which predicts the risk from git meta data. This model is trained with supervised learning where the label in the training data (vulnerability or not) is derived from associating a commit with a later bugfix or not in the same place. The model is then applied to previously unseen commits in the hope to estimate the risk of a bug. Unfortunately no results are shown of how good this model performs in practice.
Apart from this there are some patterns associated with the meta data to be expected, like: Changes very late in the day have probably a higher risk since the developer might be exhausted already from all the work. Some developers tend to introduce more problems than others since they are less experienced. Small commit message for large commits might be associated with more vulnerabilities too. Commits in areas where lots of vulnerabilities occur are more risky than others. Etc.
But directly detecting a vulnerability from the meta data is the wrong expectation. At most one can decide which  commit  have a higher risk than others in order to more thoroughly review the more risky commits.


Is there a list of safe/normal/expected SUID files? Exploitable SUID executables are a basic privilege escalation vector. But just doing a search for all such files turns up a bunch of results on any linux system, most or all of which are presumed to be safe.

How, other than by long experience with linux systems, is one able to scan the list returned by find / -perm -u=s -type f 2>/dev/null for the potential needle in a haystack? Is there a list of known/safe/expected SUID executables that one could compare against? Or a script that does this for you?

Is there a list of known/safe/expected SUID executables that one could compare against?

Not really, largely because all modern Linux distributions are package-based.  There's no single monolithic standard set of files, because installations vary easily based on which packages are installed.  That said, packages also provide listings of included files, making it easy for you to check whether a SUID binary is legitimately installed or not.

  Or a script that does this for you?

There are two simple ways to approach this - you can verify individual files against their package, or you can dump a list of SUID files out of all packages.

For example, let's say you're looking at /usr/bin and you're worried about the chfn SUID executable.  On an RPM based distribution, you can Verify the file against the package:

# rpm -Vf /usr/bin/chfn; echo $?
0
#

(The 0 exit code indicates that no discrepancies were found; the file is as expected based on the package parameters.  You can see a list of the checks that RPM Verify performs.)

On a Debian-based distribution (like Ubuntu, Mint, ...) you'll be dealing with deb packages, which have a less centralized approach than RPMs.  The same overall effect can be achieved after installing apt-file and debsums:

# apt-file search /usr/bin/chfn
passwd: /usr/bin/chfn
# debsums passwd | grep /usr/bin/chfn
/usr/bin/chfn                                           OK
#

You could write a tool to enumerate package listings to find SUID files, to verify them, and to compare your list against a list of what's actually on the file system via find.  (Note that with RPM, at least, you can verify all files in all packages with just rpm -Va, but you'll find that's a bit chatty and more than just SUID files).

For example, you could loop over all installed packages (rpm -qa) and, for each package, list out the SUID and SGID files:

# rpm -qlv util-linux-ng-2.17.2-12.28.el6_9.2.x86_64 | awk '$1 ~ /s/ {print $0}'
-rwsr-xr-x    1 root    root                    77560 Dec  5  2017 /bin/mount
-rwsr-xr-x    1 root    root                    53480 Dec  5  2017 /bin/umount
-rws--x--x    1 root    root                    20184 Dec  5  2017 /usr/bin/chfn
-rws--x--x    1 root    root                    20056 Dec  5  2017 /usr/bin/chsh
-rwxr-sr-x    1 root    tty                     12016 Dec  5  2017 /usr/bin/write
#

and use that to build your list of expected SUID files.


Is open-to-all CORS safe for non-cookie-based authentication schemes (e.g. OAuth) I'm building an API with both protected and public endpoints, and I'm protecting it with OAuth 2's various flows. I want this API to be open to the world - the main consumer website won't even be on the same origin as the API server. So I'm planning to implement CORS.

Many texts warn about malicious third parties "sending requests as the user", but I'm not sure what they mean by that. I assume this is similar to how CSRF works - as in, the requests get sent across with the user's cookies.

If this is the case, since my OAuth 2 authentication scheme uses tokens passed around via HTTP header or a GET parameter, wouldn't this not be an issue at all? My service doesn't even touch cookies at all.

Any third parties attempting to do a protected operation on behalf of the user wouldn't have access to a valid token (which is stored on local storage or in-memory). Or unless the user explicitly invokes an OAuth 2 flow, gives the third party a valid token, and it uses that (working as intended) - or it's not an operation that requires the user to be authenticated, which would work (also working as intended).

Of course, as we all know, when I assume I make an ass out of oh god we're compromised there are kittens everywhere, so I could very well be wrong and there's bigger security gap than just cookies. Thanks!

"sending requests as the user", but I'm not sure what they mean by that. I assume this is similar to how CSRF works

Exactly.

  as in, the requests get sent across with the user's cookies.

CSRF doesn't necessarily require cookies.  It's just easier with cookies because they're automatically attached to any request to a particular origin.

If the authorizing credentials are guessable or stealable then a third-party iframe can forge a request with them.  CORS just makes it easier to forge a request with headers that aren't usually part of a browser initiated GET or POST.

If you're doing authorization via secrets in the URL, I'd make sure your CORS service includes the appropriate headers so that you're not vulnerable to history sniffing and similar side channel attacks.  OAuth's embedded parameters should have enough entropy that they're safe against sniffing, but there's always referrer leakage from your side to take care of, so those headers are a good idea.

  Any third parties attempting to do a protected operation on behalf of the user wouldn't have access to a valid token (which is stored on local storage or in-memory).

It looks like you've got a handle on the major attack vectors.

If it's stored in local-storage, then an XSS on any page with access to that local-storage could leak the token.

If you can't keep the token in an origin that doesn't include HTML with third-party content, then there may be tricks you can do with document.domain to limit the window of exposure to injected scripts on any page that's in the same origin as the token.

load JS that fetches and sequesters the token using closure integrity to provide an API to other JS in the page without exposing the token value itself.
change the page origin so that you no longer have access to local-storage
proceed to run the rest of the page script which might have injected content

Also, CSP might provide defense-in-depth down the road.


Why is PKCS#7 used as a response to PKCS#10? Why is the certificate that results from a CSR usually contained in a PKCS#7? The signature of the certificate is contained within the certificate itself so there's no need for an external signature anyway and looking at some of the result PKCS#7 response there's no additional signature present anyway so there's actually zero benefit from encapsulating it in a PKCS#7?

PKCS#7 is a container and can include multiple certificates. When CA responds to client it puts in the container signed certificate and all required intermediate CA certificate you may need to install in order to correctly use the issued certificate.


Have the recent Linux kernel USB vulnerabilities found by Andrey Konovalov been patched? Have the Linux USB drivers been patched for the recent vulnerabilities that have been found by  Andrey Konovalov (Google)? If not what can be done to protect against these attacks other than avoiding use of USB devices?

You can check yourself. Choose a random CVE - I chose CVE-2017-16538. It states -

  drivers/media/usb/dvb-usb-v2/lmedm04.c in the Linux kernel through 4.13.11 allows local users to cause a denial of service...

Now have a look at that file history in the repository -

https://github.com/torvalds/linux/commits/master/drivers/media/usb/dvb-usb-v2/lmedm04.c

Aug 20, 2017 media: rc: rename RC_TYPE_* to RC_PROTO_* and RC_BIT_* to RC_PROTO_BIT_*
Jun 24, 2017 media: dvb-usb-v2: lmedm04: remove unnecessary variable in lme2510_st…

So no - it doesn't look like that one has been fixed. As /u/Sonickyle27 showed many of them do have fixes but it looks like they haven't been accepted and merged yet.

Saying this there is technically the possibility distributions may have patched it themselves.


Opening port 53 on server Risks? I looked about but couldn't find a similar enough question.

I have some remote servers positioned on clients networks, which provide various services (raspberry pi) - and their firewall config is as follows:

Only specific IP addresses INPUT and OUTPUT to specific ports. Everything else is dropped. Key only SSH connections allowed from my own network.

Problem:
One of the provided services is an email campaign creator, which send out the campaigns on behalf of the client, so the client has to be able to set the SMTP server of their own email provider.

Until now, I have been doing the setup for them, and setting the server as IP not hostname, then adding the relative rule in iptables. I would like to change this and open 53 for UDP DNS requests as follows:

# DNS Hostname Resolution
/sbin/iptables -A OUTPUT -s $ip -p udp --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT
#Return Path
/sbin/iptables -A INPUT -d $ip -p udp --sport 53 -m state --state ESTABLISHED -j ACCEPT

Are there any security holes I am completely overlooking here?
Is there anything I could do to make this safer?

Any advice is appreciated.

Correct me if I am wrong, but it sounds like you are running an authoritative DNS server for your client's domain, and people will need to be able to query this server from the public Internet. For security, authoritative DNS servers at least have the following settings:

Queries for other domains should be ignored or refused
There should be rate limiting to limit the number of DNS requests per second from a single IP address, to prevent DNS amplification attacks.

A DNS amplification attack is essentially when an attacker leverages your DNS servers bandwidth to launch a denial-of-service attack on another target. DNS is normally a UDP protocol, meaning it is easy to spoof the source IP address. If an attacker wants to use your DNS server for an amplification attack, they would simply make tons of queries to your server while spoofing the IP address of their target. Your server would end up sending all of the DNS replies to the target, causing a denial-of-service. Limiting the rate at which a single IP address can send queries will mitigate most of these risks.

If I mis-read your post and you are NOT intending to run a DNS server accessible to the public Internet, then you should configure the server to only respond to queries from the specific IP addresses that need to query it.

Finally, you should keep whatever DNS server software you're running up to date. The most popular DNS server software, BIND, has historically had some major security bugs. Running an old version of BIND could open up some serious vulnerabilities on your server.


Is there a way to use private certs for accessing private websites that doesn't require installing a root cert? I recently started a new consulting contract. The company I'm going the work for asked me to manually install a root certificate followed by a client certificate in order to connect to their work website. I'm on Mac and I use Chrome as my default browser. Looking in Chrome settings there's a link to manage certificates. Clicking it just opens the Mac Keychain Access app. Adding the root certificate there says

Company Name CA
Root certificate authority
Expires: Sunday, December 7, 2020 17:02:50 Pacific Standard Time
"Company Name CA" certificate is not trusted

Reading other Q&A this seems bad

Employer wants me to install root certificate to work remotely - privacy concerns?

Basically when I'm on their network they can read all my internet traffic. Not that I expect them to do that, it's a small non IT company. But still, I don't like the idea.

For now I'll setup a VM and install the root cert in that and use the VM solely to access their site.

My question though is: Is their some solution they could have used that would limit things so that their root cert only works with their domain / IP address rather than having it be a root cert and all the issues that entails?

Given that authentication happens with their client cert I'm guessing the root cert is only needed to validate the client cert. If so is their some other way they could have/should have generated a client cert that wouldn't require me installing a root cert?

If you are using Chrome, you could generate an SPKI fingerprint from the company's public key:

openssl x509 -pubkey < "pubkey.pem" | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64 > "fingerprints.txt"

Then you can start Chrome from the command line with this flag:

--ignore-certificate-errors-spki-list=$(cat fingerprints.txt)

Then chrome will treat any certificates with that fingerprint as valid and won't show the red security error in the URL bar. This will only last for as long as Chrome has that command line flag.


Securing internet connection with hostile ISP Please excuse the lack of details, you can understand why. I have a friend in a foreign country who is certain that he is a surveillance target of his local government. Other people he knows in his same category have already had their internet connections spied on, and seen contents of their emails leaked. He refuses to use his local ISP because the government runs it, so he uses another means of internet but which is very unreliable.
He really would like to use a landline ISP for it's stability, but knows he can't trust it. I thought of setting him up with a serious firewall (like pfSense) with a permanent VPN tunnel to a provider that is based outside of his country.
Given these considerations, would this be a safe solution? Or rather if the ISP is compromised, are all bets off?

An encrypted VPN out of country is the classic approach.
Set up correctly, all the ISP will see is that there is an encrypted tunnel to the VPN.
Common VPN errors include:

Failing to make sure that all of the DNS traffic moves through the
VPN
Failing to make sure the connection drops completely with no auto
reconnect in the event the VPN is disrupted.
Failing to select an appropriately reliable VPN

The stronger and potentially easier solution in many cases is to use Tor. Simply download the TBB (Tor Browser Bundle) and use that for internet traffic.
The ISP can see that Tor is being used, but that's all.
In either case, use a reliable email service.
All of these tools are to protect against outside monitoring and intrusion. None will protect against foolishness such as logging into an identifiable account attributable to your friend and posting or emailing content you don't want attributed.


Gaining root access on Ubuntu 14.04 I am taking a Computer Security class and I am supposed to harden my system really well but I am supposed to leave one "hard backdoor" for the adversary to gain root access.

I have been trying to figure something out for two days now and as I am a total beginner, I still can't figure out what would be a good idea to do this.

I am running Ubuntu 14.04. Is there some backdoor a beginner like me can give the adversary to gain root?

Thanks in advance.

Backdoor for what? Future network exploitation or privilege escalation from the console?

why not put a password and a shell on some system account that nobody will notice -- for example change /etc/passwd:

from:

news:x:9:9:news:/var/spool/news:/usr/sbin/nologin

to:

news:x:9:9:news:/var/spool/news:/bin/bash

and
    sudo passwd news

Don't make news a sudo user (too obvious), but leave a cron job that runs with root privileges and is world writable (or just writable by news).

Another option is to add your public key to an admin's authorized_keys file.

now you need to run programs. one trick is to setuid on some random script you can write to.

another trick is to leave a program that cron executes as uid=root as world writable, and update that file to elevate your privileges.


Transfer requests for localhost zone on my bind DNS server I use Debian stretch and Bind 9.10.3 as my DNS server.

Today I saw the following entry in my log file:

Apr 17 23:04:22 ns named[111]: client 45.83.65.112#48974 (localhost): transfer of 'localhost/IN': AXFR started (serial 2)
Apr 17 23:04:22 ns named[111]: client 45.83.65.112#48974 (localhost): transfer of 'localhost/IN': AXFR ended

The IP address belongs to zone dns-ops.arin.net. and whois points to INTERNET-RESEARCH-NET.

Do I need to be concerned?
Why do they transfer the localhost zone?
Why is this transfer successful? (*)

(*) My config is largely the default Debian one. Importantly I have not modified the stock named.conf.default-zones file, i.e. no transfers should be allowed at all:

zone "localhost" {
        type master;
        file "/etc/bind/db.local";
};

This is your guy: https://www.alphastrike.io/

In their own words:

  Alpha Strike Labs are a security consulting company specialized in
  industrial security and advanced security assessments. Based in Berlin
  and Vienna, we pride ourselves on offering high-end professional
  services in various areas of Cyber Security.

  Do I need to be concerned?

In short, no. But nowadays most DNS servers are configured to deny zone transfers, because that makes reconnaissance of your infrastructure a bit too easy. On the other hand, this is not secret information. A good chunk of your zone can be reconstructed from indirect methods like scanning your IP range and doing reverse DNS.

  Why do they transfer the localhost zone?

Generally speaking:

An entity that can enumerate your zone can figure out all the hosts you have declared, and there are legitimate reasons for this: research. A number of outfits such as Internet security companies probe the Internet for research and statistical purposes. A very common example is measuring the market share of Internet software vendors like web or mail servers.
That could have been a search engine too. They have to use every trick to discover, craw and index new hosts that would otherwise go unnoticed.
Bottom line: any machine that is exposed on the Internet is going to be probed all the time, and not all probes are malicious.

But the interesting question here is: why do they transfer the localhost zone specifically ? Normally the zone looks like this:

localhost.      604800  IN  SOA localhost. root.localhost. 2 604800 86400 2419200 604800
localhost.      604800  IN  NS  localhost.
localhost.      604800  IN  A   127.0.0.1
localhost.      604800  IN  AAAA    ::1
localhost.      604800  IN  SOA localhost. root.localhost. 2 604800 86400 2419200 604800

So I am not sure what kind of juicy details (internal hostname ?) they are expecting to find here. You could contact them directly and ask. A legitimate company should not be ashamed to explain why and how they are probing your systems.

  Why is this transfer successful? (*)

AFAIK this is allowed by default in Bind. You can deny AXFR on a per-zone basis or globally. To disable it globally you could add this entry: allow-transfer {"none";}; in named.conf. If you have slave name servers that sync with a master using AXFR, then whitelist their IP addresses or range. Otherwise zone transfer can be safely disabled  as there is no reason to expose your zone to the whole world.

See allow-transfer


How to communicate a positive feeling about ethical hacking to non technical people? Summary:

For most non technical people, who hear about computer security either in the news because of some giant breach or in the movies, there are two kind of hackers:

The professional people hired by often large company to ensure network security. These are the good guys.
The delinquents, who act on their own outside of any professional and legal frames. These are the bad guys.

However such people are missing that before being hired as a professional IT security engineer, one need to develop certain knowledge which must mandatory pass through personal experience.

Moreover, such news and movies added to the technical nature of this matter brings some kind of "mysterious" feeling on this subject, causing often very emotive reaction from people ranging from fascination to reject.

How can we preserve the sensitivity of other people and present ethical hacking in a positive, understandable way?

This question mainly focuses on school administration where teachers and principals may not be rightly informed on the subject and, for the sake of protecting pupils from bad influences, may be encouraged to take wrong decisions.

Background story:

(Serving as a concrete illustration of the question above)

Let me be frank here. I changed my school two years ago when I was in grade 7 (12 yo). I have always had difficulties in making new friends and this time was no exception. I had always been interested in technology and since I had nothing better to do, I got into coding and, in the process, Penetration Testing. I created my own website on penetration testing and everyone in school started calling me the hacker of the school. In this process, I made a lot of friends and often helped them solve problems related to technology.

But, you have to understand that here in India, you just need a BSc (bachelor of computer science) degree to become a school teacher. The two ladies who taught computers in my school got jealous of me over two years and went and blabbed a whole lot of nonsense to the principal.

The principal called my mother and told her that there was no surveillance at home and that she is a bad parent who is destroying my future. My mother, being the awesome person she is, believes that learning Hacking is just a way to gain knowledge and defended me

The conversation with my principal went something like this

Principal: So what do you mean by ethical hacking? (she insists on calling penetration
           testing that)
Me: Basically finding bugs in code and fixing them before a bad guy can exploit them.
Principal: But why would you want to do that? Can't companies hire people to do that?
          I'm a principal do I go and find faults in other schools? (She has been
          brainwashed)
Me: Because there are open source codes and free software and the organisations can't
    afford to hire people to do the job. Also, I think it is fun.
Principal (to my mother):Why are you even letting Rahul do all this?
Mom: Because I think this is a part of learning and since he is getting good grades, I
     don't see anything to complain about.
Principal: But why do it at this age?
Mom: Because this is his passion.
Principal: There is no surveillance at home. He is going down the wrong path. I am
           banning him from using school computers and forbidding him from taking
           computers as his hobby. (referring to the hobby subject in school)
Mom: If he's going down the wrong path, then take him in the computer hobby and bring him to the right path.
Principal: We cannot trust him.
Mom (sarcastic and bitter): So should we take away his phone, lock away the computers,
                            destroy his passion?
Principal: Mrs <insert surname here>, If I was in your place, I would have done that long ago.

Shortly after this, I changed my school again. How can I prevent a similar situation from taking place at my new school?

PS: I'm in grade 9 now (14 yo)...

Sadly I think that such situation isn't new and isn't going to disappear in the near future. I don't know if you ever read the Hacker Manifesto? This text was written in the eighties, but chances are that you will recognize yourself in some aspect of this text...

It is interesting in your text that you first explain that you had difficulties to make friend, so you thought how to resolve the issue and finally made up a solution. So now you are reaching step two: how to deal with the authorities (I could limit it to the school administration, but I think the problem is more general than that, the school administration people just react to the wrong image that hackers have in the usual (sub)culture).

I worked as technical support engineer for a few years. Starting from day one, we were told to use the word "issue" as few as possible, and in all case to avoid the word "problem" at all cost. Instead, when communicating with a customer, we should only discuss about "unexpected behaviors", "fixes" and "improvement".

This might sound silly, but the fact is that using positive words makes your audience in a positive feeling, while using negative words just amplifies all the wrongs feelings they may already have.

So my advice for your next step, now that you have the technical skills, would be to develop your "marketing side".

You talk about bugs, exploits... Arrgh, such twisted, chilling, horrible words are they to the ears of the principal. Some kids loose themselves by touching drugs, this one touches BUGS! May someone save his soul!

Would you talk instead of sharing good practice from instance. In some way, ethical hacking is just about that: someone does not apply some good practice, causing a security weakness on his system, so you share good practice with him for his and others safety.

Would you imagine the principal stating "I'm a principal, do I go and share good practice with other schools"? I suppose you get my point ;). Added to the fact that using positive words makes people in a more positive feelings, it also lets less room for them to argue. It is easy to criticize someone hacking into systems, breaking security measures and exploiting bugs. It is less easy to criticize someone for sharing good practice, for acting as a good and responsible civilian taking his share to participate to public safety.

Another point is, I do not know the exact relationship you can have with the people working for your school, but it would be of great help if you could "sympathize" with some IT staff or related. The goal here being to be visibly helpful, so it would not be kid's word against principal's words, but that someone else working for the school (and thus someone whose words are more trustable from principal's point of view) can testify to the fact that, for instance, you gave some advice to solve a network or computer issue, that you are involved in helping other's difficulties, etc.

I'm conscious that there is most likely no real "IT people" in the school, the goal here is just to be flagged as a clean, helpful, benevolent and responsible person. If you don't do anything, due to your unusual and misunderstood hobbies, you are flagged as an irresponsible nasty looser by default. It's up to you to try to reverse this flag by choosing which image of yourself you want the other to perceive. This passes by the words you employ and by your visible actions, so choose both well.

At last, you may also begin to build some kind of a CV, it could be as simple as:

A listing collecting where and how you brought your technical help. The more concrete the better: "I'm finding bugs to prevent bad people from exploiting them" does not tell anything to the principal (except that your deal with something related to bugs and bad people), "the website example.com had a flaw allowing anyone to access all user's personal information, I informed the site owner so he was able to correct it": how one can reasonably be against such initiative?
If you participated to some public competitions, no matter the result, such competition would be steps towards the certification exams you will encounter later in your professional life,
If there is any public project in which you were involved. Involvement implies relationship and responsibility, and the links and participation you create now may be useful for you in the future (having participated in a open-source project is always a large bonus when applying to high schools).

Writing and maintaining such listing will be useful for you in the future, and I would definitively not imagine a principal arguing that you are destroying your future if you say that "IT security engineers are effectively needed and largely hired by companies, and I'm studying to become one of them. By the way here is my CV"

To summarize all this in three words, it would be communicate, communicate, communicate. Choose your words, avoid anything which might be wrongly perceived, cooperate with the school administration so they learn to know you a good way, whenever possible use your personal experience for school projects (I remember for a subject-free presentation in English course having presented the basis of reverse engineering to my schoolmates ;) ).


Is Django's built-in security enough? I have learned that Django provides built-in protection against the three main types of web app attacks (SQL injection, XSS and CSRF), which is really awesome.

Yet I have spoken to a few Django developers and they have essentially told me not to rely on these too heavily, if at all.

They told me to treat all data as "unsafe" and handle it appropriately.

I have two questions to ask everyone about this:

Can Django's built-in security features be relied upon?
What do my friends mean by "handle it (unsafe data) appropriately"? I know its about escaping and/or removing unsafe phrases and/or characters, but my biggest fear is that if I try to do that myself I will end up producing a "filter" that is worse off than Django's built in stuff. Does anyone have any guides for building on top of Django and not overriding it, in this regard?

SQL injection.  If you use Django's object-relational mapper (ORM) layer, you are basically protected from SQL injection.

The only caveat is that you need to avoid manually forming SQL queries using string concatenation.  For instance, do not use raw SQL queries (e.g., raw()).  Similarly, do not use the extra() method/modifier to inject raw SQL.  Do not execute custom SQL directly; if you bypass Django's ORM layer, you bypass its protections against SQL injection.

CSRF. Django's built-in CSRF protection is good.  Make sure you enable it and use it everywhere.  Django provides ways to disable it locally or globally; obviously, don't do that.

It is important that you make sure that GET requests do not have any side effects.  For requests which can have a side-effect, make sure you use a POST request (and do not accept a GET request for those).  This is standard web design, but some developers screw it up; Django's built-in CSRF prevention assumes you get this right.

There are some caveats if you have subdomains (e.g., your web app is hosted on www.example.com and there is a subdomain alice.example.com that hosts user-controlled content); the built-in CSRF protection might not be sufficient in that case.  That's a tricky case for a number of reasons.  Most web applications won't have to worry about these caveats.

XSS. If you use Django's template system and make sure that auto-escaping is enabled, you're 95% of the way there.
Django provides an auto-escaping mechanism for stopping XSS: it'll automatically escape data that's dynamically inserted into the template, if it hasn't already been escaping (see e.g., mark_safe, safe, etc.).  This mechanism is good stuff, but it is not quite enough on its own.  It takes you much of the way to stopping XSS, but you still have to be aware of some issues.

In particular, Django's auto-escaping will escape data sufficiently for most HTML contexts, but in some special cases you must manually do additional escaping:

Make sure you quote all attributes where dynamic data is inserted.  Good: .  Bad: .  Django's auto-escaping isn't sufficient for unquoted attribute values.
For data inserted into CSS (style tags and attributes) or Javascript (script blocks, event handlers, and onclick/etc. attributes), you must manually escape the data using escaping rules that are appropriate for CSS or Javascript.
For data inserted into an attribute where a URL is expected (e.g., a href, img src), you must manually validate the URL to make sure it is safe.  You need to check the protocol against a whitelist of allowed protocols (e.g., http:, https:, mailto:, ftp:, etc. -- but definitely not javascript:).
For data inserted inside a comment, you have to do something extra to escape -s.  Actually, better yet, just don't insert dynamic data inside a HTML comment; that's an obscure corner of HTML that's just asking for subtle problems.  (Similarly, don't insert dynamic data into attributes where it is crazy for user input to appear (e.g., foo class=...).)
You still must avoid client-side XSS (also known as DOM-based XSS) separately; Django doesn't help you with this.  YOu could read Adam Barth's advice on avoiding XSS for some guidelines that will help you avoid client-side XSS.
If you use mark_safe to manually tell that Django that some data has already been escaped and is safe, you'd better know what you're doing, and it really better be safe.  It's easy to make mistakes here if you don't know what you are doing.  For example, if you generate HTML programmatically, store it into the database, and later send it back to the client (unescaped, obviously), it's very easy to make mistakes; you're on your own, and the auto-escaping won't help you.

The reason why you have to do something extra for these cases is that Django's auto-escaping functionality uses an escaping function that is supposed to be one-size-fits-all, but in practice, one size doesn't always fit in every case; in some cases, you need to do something extra on your own.

For more information about what escaping rules to use in these special contexts, see the OWASP XSS cheatsheet.

Other stuff. There are some other things you didn't mention:

I recommend using SSL sitewide, if possible, and in that case enabling HSTS and marking all cookies with the 'secure' flag.  Search this site for details on the tradeoffs of doing so.  If you want to do so, Django provides support for this, and there are some resources on this site as well: Trying to make a Django-based site use HTTPS-only, not sure if it's secure?
I recommend enabling Django's clickjacking protection.
Follow other advice in Django's documentation.
You could check out django-secure for some utilities to help you avoid forgetting some basic security steps, particularly if you are using SSL.
All of this good stuff is not a panacea.  It doesn't mean you can ignore security from here on.  It'll help you avoid some of the most common mistakes, but you still bear the ultimate responsibility for building a secure web application.

For more information. See Django's documentation on security, including the chapter on security in the Django book.


Microsoft ASMX Web Services Test form available on remote machines I have been doing some research about Web Services security. I noticed that some sites are using Ajax and JQuery to consume ASMX WebServices. I navigated to the Web Service EndPoint and I realized that, from my machine, I was able to use the Test form to consume the service,a part from that I was able to see the HTTP mechanism to send SOAP over HTTP. Making this information available to remote users could drive to unwanted  invocations and it could also drive to DoS attacks.

Do you believe that showing this Test form to remote users could drive to a service attack?

When releasing a ASMX/WCF/SOAP webservice to production it's recommended to disable metadata access and turn off the test entry form. Yes, you should disable the test form for ASMX, and better yet, you should upgrade the ASMX to a WCF endpoint.

Will leaving it on lead to DoS attacks? No, probably not. Will someone try and enter in data if they come across it? Yeah. Where the problem lies though is the WSDL metadata. With the WSDL you can consume the web service from another application and call the service directly without having to go through the test form. If you turn off metadata, you can't get to the WSDL, so only clients that you trust should know about the interfaces for the service.