It should as safe as the boxcryptor encryption when I store the salts for the key derivation (for MAC & content) in the ciphertext, is it?
Yes, that's the definition of a salt, a salt is public (otherwise it is commonly called a pepper). E.g. the various text encodings of bcrypt store the salt next to the hash (which has the same security consequences as storing it next to the ciphertext).
Do I really need two salts & keys?
And using two salts implies deriving the key multiple times. That's bad, especially if that is done by using a password derivation twice. This looks like the case for your scheme. Performing PBKDF2 twice or for more output than the hash delivers will double the amount of work you have to do while an attacker has to perform the 50K operations only once (per try).
Using HKDF or any other KDF over the output of PBKDF2 is sufficient and much more efficient. You can just use two different labels (identifiers) for the two keys - if two keys are needed. This is also present in the answer of Codes that you linked to.
Another trick is to extract 256 bits of output from PBKDF2 and then split that into two 128 bit keys (or two 256 bit keys for PBKDF2 with HMAC/SHA-512). You probably don't need to extract an IV if the salt is always different (because the derived keys would then also always be different). Or you can generate a separate IV: your choice.
No, you don't need two keys either. You could use a mode of authenticated encryption such as AES-GCM. Then you'd only need just one key. If you use HMAC with a single key then you probably cannot prove that it is secure. But the chance that you run into practical security issues is minimal.
Don't change the MAC to CBC-MAC or another MAC based on AES if you use a single key, because that could make your scheme vulnerable to attack. The protocol using a single key and separate cipher and MAC is more brittle: it could break catastrophically if you implement it incorrectly.
