Does the Oracle Database Built-in Password Protections prevent pass-the-hash or replay attacks?

I assume you are talking about the TNS login process and not about the stored hashes. But just in case: Oracle up to 10 stored password hashes as simple 2-iteration DES over uppercased user+password since 11.1 it is a salted SHA-1.

For the TNS Logins with password authentication (there are others like Kerberos), the protocol use a challenge response where the password hash is encrypted with a session key. Starting with 10g the session key is larger and contains a client and a server part (as opposed to only a server part before).

The most problematic aspect of this is, that if you have the password hash you can use it to brute force a sniffed login package.

So short answer to your question: yes (but it is not very secure).


HTTP response splitting attacks work when user data (including newlines) can be injected into HTTP headers.

For example, let's take this response:

 HTTP/1.1 200 OK
 Date: Mon, 23 May 2005 22:38:34 GMT
 Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
 Last-Modified: Wed, 09 Jan 2013 23:11:55 GMT
 Accept-Ranges:  none
 Content-Length: 1234
 Connection: close
 Content-Type: text/html; charset=UTF-8
 Cookie: test=123&username=Polynomial

 <html>
 ...

Now let's assume I can change my username arbitrarily, and include CRLF (newlines) in the field. I could then inject my own content into the page.

For example, I might set my username to Polynomial\r\n\r\n<script>alert(document.cookie)</script>, which would result in the following HTTP response:

 HTTP/1.1 200 OK
 Date: Mon, 23 May 2005 22:38:34 GMT
 Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
 Last-Modified: Wed, 09 Jan 2013 23:11:55 GMT
 Accept-Ranges:  none
 Content-Length: 1234
 Connection: close
 Content-Type: text/html; charset=UTF-8
 Cookie: test=123&username=Polynomial

 <script>alert(document.cookie)</script>
 <html>
 ...

As you can see, the JavaScript was injected into the page. This is a form of XSS / DOM injection via the splitting attack.

Including user data in a request isn't quite as bad, since the server should treat user requests as untrusted anyway. As such, AJAX requests shouldn't be an issue. This becomes even less of a problem when you consider the fact that most major browsers have disabled or limited the javascript: handler in the URL bar, in order to limit the potential for attacks.


What problems if any are caused by opening a port in the firewall that no program listens on?

It is likely that the port you have open will always show as being in a different state from other ports if someone does a scan of your IP address, so it would make sense to ensure that there definitely isn't anything listening when the game server is shutdown (although if the game has vulnerabilities it probably does not matter if it is listening all the time or only when you are playing with friends).

You can check that there is nothing listening on the Factorio default port when the game is shutdown by using netstat see here https://stackoverflow.com/questions/48198/how-can-you-find-out-which-process-is-listening-on-a-port-on-windows. If nothing is listening any inbound packets will be either quietly dropped or possibly result in an Ack Reset (depending whether it is UDP or TCP based traffic). In theory leaving the port open in the firewall should not be a problem, but I would err on the side of caution and disable the rule that allows the traffic when it is not required.

You might also want to look at your router and see whether you can limit the inbound connections to the IP addresses of your friends, this would help to reduce your exposure to attackers (this is a game which is in development and could well have exploitable vulnerabilities), but if they are on dynamic IPs this could be a bit of a pain to maintain depending how often you play.


How to alert webmaster if he does not put contact address

If you're looking to get in touch with a website owner then there's a couple of possibilities.

Some domains might map standard names (e.g. webmaster@[domain], contact@[domain], info@[domain])
DNS records may well contain a contact name/address.  So running 'whois' will return that info.
Also IP address whois can return contact information.  So running 'dig [web server addresss]' and then running 'whois' on that IP address might provide more info.

One thing to watch is that some people don't like their security flaws being pointed out to them so you might want to use an e-mail account that doesn't directly tie back to you, in case they decide to get awkward..


I would not consider using a family member or friend's email to be a good idea, for reasons you mention yourself or simply if they ever change a password. I would create a new email address and use that, but for no other purpose. That way you would also not be putting others at risk.

2-Factor is not a bad idea. The harder you make it for an attacker to compromise you - often by adding a personal touch, the better off you are. Nothing is ever completely secure based on the determination and skill level of a person or team of people determined to break in but by requiring steps and delaying their efforts allows more time for intrusion detection and countermeasures.

If you have more than one account online, like a bank account, a paypal account, and a main email account for example (among others) it might be smart to have different email addresses for recovery for each one. That way if one is compromised, then the others are not also compromised.


Custom socket server on the internet running as root

That the code "runs as root" is mostly irrelevant. Root or non-root is a distinction that makes sense only locally to a machine, and only if you want to contain some potentially hostile code (e.g. hijacked server code) without bringing down the whole machine. This is the mainframe model from a few decades ago. At that time, it was believed that you could have a Unix (or Unix-like) system such that non-root process could be kept apart from each other, without any possibility to evade that containment and reach other process on the same machine.

This belief hardly holds nowadays. Local privilege escalations are plentiful; it is very hard to plug them all while maintaining a fully functional environment. In general, it is safer to assume that any hostile code running on the machine, under any user, will be able to take control of the whole system, unless some stronger containment measures are applied, such as (in increasing levels of complexity and containment) chroot, jail, virtual machines. In any case, a process that calls mmap() on /dev/mem can gain full control on the local machine (possibly the virtual machine if you go the VM road).

The conclusion of all that is that if your machine is hacked into, and making it Internet-facing sure increases that likelihood, then you should ask yourself what could happen if it gets subverted by hostile outsiders. Changing the code not to run as root and not to mmap /dev/mem does not substantially change things here. What matters is whether the code has been well designed, reviewed, tested, documented and maintained.

I must say that a direct mmap() on /dev/mem sends a strong signal of "these guys should not be allowed to go near a keyboard". I don't know why you are doing that in your server(*) but it seems real weird. Mapping physical RAM in your address space is not a security issue, unless you cling to the outdated mainframe model; however, doing very funky things is a security issue because it makes design, reviewing, testing, documentation and maintenance much harder.

(*) My best guess is that your server interacts with a custom piece of hardware that lacks a specific kernel driver, and does I/O by mapping its circuitry in the physical address space, like, say, a graphics card. It would be cleaner, and thus safer, to actually write an appropriate kernel driver.


Use a backslash as the last character in user. For example, for the inputs user\ and or 1=1 -- the following query is run:

select * from users where username = 'user\' and password = ' or 1=1 -- '

Where the string input is interpreted like this:

select * from users where username = 'user\' and password = ' or 1=1 -- '


it is possible to decrypt HTTPS with the (private, public) pair if it uses DHE?

When TLS/SSL handshake starts, the first step is, server is authenticated using a private key associated to the server's certificate. In a 2nd step, client and server exchange a session key used to encrypt the payload of the connection. The session key is used for one session means when the session is closed the same key can't be used to encrypt the traffic of another session. Now the problem is SSL/TLS often use RSA cipher suites in which the session key is derived from private key. So the session key can be calculated in future if the underlying private is known.

DHE and ECDHE provides Perfect Forward Secrecy(PFS), means session keys are not derived from private key. So the attacker can not decrypt the traffic even when he has the private key used in the session handshake.

In DHE(not DH) the session keys are calculated using the Random Numbers.

Conclusion

You can't decrypt the traffic using private key when DHE or ECDHE is used.


How does DuckDuckGo know my native language even though I am using a VPN in a country with a different language?

One possible explanation is that DuckDuckGo is using the headers that are sent in your request to determine their display.  For example, it is very common to use the Accept-Language header to determine in which language a webpage should be displayed.  This header is set by default in all modern browsers based on the language preference settings.  My browser, as an example, sends Accept-Language: en-US for all requests, letting the target site know that they should attempt to send back US based English if possible.  This does not require any sort of tracking to be used.

If you visit https://duckduckgo.com/settings you can see what the language settings are.  The default language is Browser preferred language


Self-teach pentesting/CEH skills ethically

There are many "boot to root" and "vulnerable by design" challenges you can have a go at completely legally. You'll need some VM software, and make sure you set the network settings on it so that the machine can only be seen from your internal network!

http://www.kioptrix.com/blog/?page_id=135 - Has several challenges which can be done this way.
http://hackingdojo.com/pentest-media/ - As above

Holynix is another (I can't link more than 2 due to new account here).

If you search for g0tmi1k's blog, he has the solutions up for most of these - don't look even if you get stuck in my opinion. Just use them to work out how you could have done it faster/better afterwards.

Good luck!


How does Authenticator gets the PMK which is used to calculate PTK?

This Master Key is passed in the Access-Accept message itself. RADIUS decoder for wireshark says it as Vendor specific attribute so I was not able to identify it initially.
Below RFC links explains in more detail about the Vendor specific attributes key passed during Access-Accept message.

https://tools.ietf.org/html/rfc2548#section-2.4.2

=====================================================
Wireshark traces of Access Accept showing Key transfer to Authenticator.


OAuth2 Implicit Flow: Possible Attack Vectors of Refreshing Token via CORS?

Instead of going with a completely different approach that as you mentioned would warrant a more thorough review from a security standpoint I would suggest leveraging what's already specified in OpenID Connect - the support of an immediate authentication mode through the use of prompt=none.

  While SPAs cannot use refresh tokens, they can take advantage of other mechanics that provide the same function. A workaround to improve user experience is to use prompt=none when you invoke the /authorize endpoint. This will not display the login dialog or the consent dialog. In addition to that if you call /authorize from a hidden iframe and extract the new access token from the parent frame, then the user will not see the redirects happening.

(source: Auth0 - Which OAuth 2.0 flow should I use?; emphasis is mine)

Your authorization server will need to support this additional request parameter and also support auto-approval for requests/scopes that were already authorized by the user.

The main benefit of this approach is that it's leveraging most of what already existed so it does not significantly increase the attack surface as it would be the case for a completely new and different approach.

Check the Auth0.js library for a reference implementation in how this type of silent authentication could be accomplished.


Are there additional security risks posed by rooting an Android device?

The SuperUser app acts as a gateway to running things as root, which should prevent apps from becoming root directly without your approval. However, if an app you approve to run as root has a vulnerability, a malicious app might be able to exploit it to gain root.

Other security concerns include:

Taking advantage of the more lax side-loading abilities (i.e. loading non-Play Store apps) which are not vetted in the same way that Play Store apps are.
Leaving USB debugging enabled by accident, after the rooting process, may allow a host device to attack your Android device after rooting.
Leaving "Unknown Sources" enabled after rooting may also lead to malicious applications being launched, though this still (usually) requires user interaction.


How to identify L2 devices in a Wide Area Network?

Information from layer 2 are usually not propagated to the higher layers because they are not needed there. Exceptions are protocols like ARP but this is only visible inside the local network. This means it is not possible to directly detect layer 2 (link layer) devices unless you are connected to the same link or inside the same local network (ARP). You might try to infer the possible effects of such devices based on irregularities in the network or timing but most will probably be invisible from remote.


Explaining a buffer overflow vulnerability in C

On 32-bit x86 processors, with the ELF format in use on Linux systems, the function call convention states (page 3-12) that:

  A function that returns an integral or pointer value places its result in register %eax.

In your program, the last element of main() is a call to strcpy(). That function returns a copy of its first argument, here a pointer to the buf[] array. So, when the end of main() is reached, %eax still points to the buf[] array, so that's where the call *%eax will jump: into the array which contains the shellcode.

If unsure, see the generated assembly code:

$ gcc -m32 -z execstack -fno-stack-protector prog.s
$ cat prog.s
    .file   "prog.c"
    .text
    .globl  main
    .type   main, @function
main:
.LFB0:
    .cfi_startproc
    pushl   %ebp
    .cfi_def_cfa_offset 8
    .cfi_offset 5, -8
    movl    %esp, %ebp
    .cfi_def_cfa_register 5
    andl    $-16, %esp
    subl    $1040, %esp
    movl    12(%ebp), %eax
    addl    $4, %eax
    movl    (%eax), %eax
    movl    %eax, 4(%esp)
    leal    16(%esp), %eax
    movl    %eax, (%esp)
    call    strcpy
    leave
    .cfi_restore 5
    .cfi_def_cfa 4, 4
    ret
    .cfi_endproc
.LFE0:
    .size   main, .-main
    .ident  "GCC: (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3"
    .section    .note.GNU-stack,"",@progbits

See at the end ? After the call strcpy, there is only a leave, then a ret, neither of which modifying %eax. So when the ret is reached, %eax still contains the value which was set by the strcpy() function, and that's a pointer to the buf[] array.

If you add a return 0; after the call to strcpy(), then the exploit no longer works, because that return 0; will set %eax to 0 before returning; and the call *%eax will jump to address 0, triggering a segmentation fault. In the assembly code generated by GCC, you would see an extra movl $0, %eax before the leave.


Is password authentication worse that signed messaging if done over SSL?

Authentication based on asymmetric keys is already supported by SSL under the name "client certificate". Indeed, a signature is involved. If you want to use a client asymmetric key, you are encouraged to use this SSL feature which is already implemented by SSL libraries.

Using an asymmetric key for authentication is useful when the identity of the client is asserted by a third party: an entity, distinct from the server, makes the initial identification (aka "certification" with certificates), and the server relies on this identification. This is a separation of roles which may or may not be useful in your context. Another way of viewing it is the following: when the client connects to the server, in a login+password scenario, then the client sends its password to the server. Therefore the server learns the password. A consequence is that the client must not use the same password if it is connecting to several servers which do not trust each other. With a client certificate, the client can use the same certificate with every server.

If you do not need the extra functionalities of certificates, then a login+password is fine. Actually, if the client works in an automatic fashion without a user entry, then the "password" is stored somewhere in the client, not typed by a human. Therefore, that password can be a bunch of random bytes, which will be much more robust against exhaustive search than a human-remembered password. Under these conditions, you may want to use SSL/TLS-PSK which will build on this "pre-shared key" and avoid the need for any certificate, neither client or server.

Similarly, if the password is indeed typed or remembered by a human, consider TLS-SRP which also needs no client or server certificate, and, moreover, tolerates passwords of limited entropy.


How to set X-FRAME-OPTIONS where 3rd Party frame is required to be loaded?

From: The X-Frame-Options response header:

SAMEORIGIN
The page can only be displayed in a frame on the same origin as the page itself.

You know this already, but I mention it to let you know that there has been, AFAIK, any vulnerability around this. By doing that, you rather added a layer of security to your web application by preventing clickjacking but this may not be enough:
X-Frame-Options is worth less than you think.


What are the security implications of pairwise master key caching in Wireless Networks?

With WPA in general, the EAP exchange results in dynamically encrypted session - one that has a different "key" for every client, and every connection, and every re-connection. PMK caching is typically found in networks that have roaming features enabled and time-sensitive applications (e.g., VOIP) - applications that can't risk disconnection because the client has to re-authenticate to the AP every time it roams.

So the risk isn't really very high. The first "phase" of security in a WPA2 Enterprise network is the authentication that occurs with the certificates (hopefully you're using mutual authentication). After a client has successfully authenticated with an AP, the EAP four-way handshake occurs, and the second "phase" of security kicks in. This second "phase" is what's cached by the AP (PMK). Depending on how long you tell your AP software to cache it for, it "forgets" the cached credentials if the client doesn't reconnect to it in the required time frame. It will basically assume the client has found a better AP and remove the cached PMK. If the client reconnects to it after the expiration time frame, it will require the EAP process to occur again, and will cache the credentials again.

As an analogy, it's like an ex-girlfriend (or boyfriend) that found someone better and left. After a certain period of grieving, you forget about them. They realize they never should have left, but if they want to be with you again, they'll have to start all over.

Edit: As for attack scenarios, it's still in a much better place than WPA2-PSK. If an attacker somehow obtains the legitimate client certificates and is able to authenticate to the WPA2-Enterprise wireless network anyway, PMK caching will be the least of an admin's concerns. Not taking into account stolen credentials, an attacker is basically looking at brute-forcing AES - something that's not an option time-wise for most attackers (thousands or millions of years to crack with today's technologies - time calculator here).


302 redirect and the body on the page (you are redirected to ...)

1- why there are html code if the browser will redirect it automatically

It's traditional from the times where 302 was new and not every client understood what it means. It is not really needed today and uselessly wastes bandwidth.

  2- if inject code in href, a javascript code can this executed before the redirection happened ? or not ?

If you have a proper 302 response, that is a Location header is present, the body will be ignored and nothing will be executed.

If no Location header is present (which would be an invalid response) it depends on the browser and context: if the URL with the bad 302 was included with img tag or was linked HTML it will often be rendered including the execution of Javascript inside the HTML. In other cases like downloads (link not leading to HTML) or script context it will instead result in an error.

There are firewalls which can be bypassed this way because they don't expect the browser to execute the body of 302 responses and thus skip inspection even if no Location header in the response indicates the target of the redirection.


How to intercept http/https requests done by an Android app in plain text?

Using a packet capture tool like the other answers suggest will give you the raw network traffic, but will not help decrypt HTTPS traffic.
For that you will probably need to install a certificate and change all traffic to use that certificate.
Tools like Burp Suite are used for this:
https://support.portswigger.net/customer/portal/articles/1841101-configuring-an-android-device-to-work-with-burp

Also, this will only work if the app doesn't do cerificate pinning, for those you might have to decompile the app into smali, remove pinning and rebuild it.


how to extract a valid digital certificate and put it on other program

What you're asking to do is possible but quite difficult. First of all you need to understand a few ideas so here we go.

Firstly, signature schemes. You've no doubt looked at digital signature schemes on the web and you might rightly ask - so why don't you just sign the whole file? Well, the answer to that is that in at least the case of RSA, you open yourself up to existential key-only forgery attacks. That is, I can generate valid signatures for different message pairs just by knowing your public key.

The solution to this is to use message digests - hashes, in other words. A cryptographically secure hash function is one that not only has preimage, but collision resistance.

So now to what you (and the NSA, and the entire Russian criminal underworld) want to do. You want to pass off a signed file as having a valid digital signature using a digital signature you found somewhere else. Okay. There are two things you can do:

You can take their public key, generate a valid message/signature pair, then try to find a pre-image of the hash that actually works. Good luck. There are no pre-image attacks on even MD5, that I know of.
You can try to find a collision with the hash value they used, and just cat the signature on the end.

Number 2 is exactly what the authors of the flame malware did - they took a valid signature and exploited an MD5 collision to make it valid.

With a whole executable that works, I hear you say? How did you not segfault?! Well, hold up a minute. See, digital signatures underpin the entire chain of certificates from root CAs down to your code. You trust root CAs because they're in your local store. You trust things they sign because their signatures are valid. Those "things" can be intermediate certificates, which can then sign other objects. You trust the chain because when you check each signature, they're all valid signatures that can only be made with the private key.

So rather than find a collision with the hash of the binary, do it with a hash of another certificate and use that collision to let you generate a cert that can sign anything and be valid in the chain.

Unfortunately since the NSA someone already did this with MD5, the world has discovered the problem. MD5 certificates are a thing of the past now and SHA1 is even being sunset, but, just in case. To the best of my knowledge, right now, nobody knows how to generate valid SHA256 collisions on demand.

So, you need to a) target the certificate chain, as ASN.1 parsers are evil and b) break SHA256.

If you want to try to reproduce this, I would recommend a copy of Windows XP which still accepts MD5 certificates (don't let it do Windows update), generate some MD5 certs with openssl then try to reproduce the flame outcome :)


Hashed passwords storage: iterations vs entropy

A message authentication code with a secret key that's unavailable to the attacker will indeed resist many attacks that resource-intensive password hashing won't.  There's no question there.  You don't even need the excessively complex three-tier key architecture; just one 128-bit secret key would be plenty.

(Side note: I highlight "message authentication code" because that's the cryptographic construct that's appropriate for your proposal.  Your "SHA512(password + secret)" betrays that you don't seem to know what construct is appropriate for what you've proposed; HMAC-SHA512(key, password) would be the better choice.)

But here's the big, difficult topic that your question completely sidesteps: how do you protect those secret keys? You say this:

  Of course the implementation would need to be secure (handmade vs more standard scrypt) and the secrets must remain unknown.

...but those two are precisely where laypersons who attempt to implement your proposal will fail, again and again!  You already have questionable crypto in your proposal (handrolled keyed hash instead of HMAC, three layers of MAC computation when just one would do), and you say nothing about how you'll make sure your secret keys don't get disclosed—which is the point on which the security of the scheme hinges!

  Moreover if a secret is revealed and must be changed, the update process would be a pain.

This can be solved with a hash-then-encrypt approach, like Dropbox has adopted (with bcrypt, however).  The equivalent in your no-iterations approach would be something like encrypt(key, hash(password)), or (scarcely) better encrypt(key, hmac(salt, password)), which would allow you to later rekey the encrypted hashes.

  I do not see such scheme rolled out on production very often though, in general the consensus is "iterations+salt or get shamed", so maybe I am missing something.

Insecure storage of long-term secret keys is really, really common, and nearly everybody who suggests using a pepper haven't really thought the key management problem through.  This is what makes key-less schemes like resource-intensive password hashing so valuable and such a strong recommendation; if we can avoid or reduce the reliance on secret keys, that is generally a plus.  Basically, key management is hard, so the fewer long-term cryptographic keys we need to store and defend the better, and the more we can mitigate the consequences of failure the better as well.

Secret keys should therefore only be considered for password hashing after:

You've adopted resource-intensive password hashing, which serves at least as a fallback line of defense if the keys are disclosed.
You have a well-thought out and well-engineered system for protecting and managing your systems' secret keys—ideally one where the keys are stored in just one secure key management system whose only purpose is to store long-term secret keys and never to leak them to any external system.  A KMS shouldn't disclose the keys not even to its clients, who instead must resort to asking the KMS to perform cryptographic operations on their behalf.  Some examples:

A hardware security module
Secret management tools like Amazon KMS or HashiCorp Vault's Transit backend.


The iWatch, like most computer equipment, is designed to be secure. However, vulnerabilities can arise which mean it doesn't really deliver the security it is supposed to. The vulnerabilities could be design weaknesses (e.g. poor encryption), coding weaknesses (e.g. buffer overruns), user error (e.g. weak passwords) and much more.

An iWatch is a computer. If it is hacked, it can be programmed to do whatever the attacker wants. It could record all the audio - even if offline - then next time it is connected to the Internet, it uploads the audio to the attacker's server.

As far as I know, there are no public exploits against the iWatch (this doesn't count). But who knows what attacks have been discovered in secret? There are plenty of people trying to create malware like this.

The cabinet is more-or-less the most confidential meeting that happens in the UK. They are certainly a target for sophisticated espionage attacks, so banning iWatches makes complete sense. The article you reference is not credible.


CEH or GIAC - Which one should I pursue?

If you are focusing on Security Testing, the CEH does seem to be a useful entry level certificate. See the answers on this question on professional certifications. It will get you an understanding of the common tools used in the industry and it is recognised by recruitment agencies.

It doesn't give you the broader view of security, as to where it fits in with real world business needs, but to be honest, that will be further down the road for you and when you want to start looking along those lines, studying CISSP (links to free resources here) gives you a wider perspective and it is a very well respected cert.

GIAC is more in depth, and requires more knowledge and experience, but is valued higher than CEH. It is not an entry level cert.


The simplest is to have it set up as an encrypted partition.

To wipe, simply lose the passphrase.

That easy.

Sure, you have to use a framework that doesn't leak the passphrase or store it anywhere accessible, but this way has been tried and tested, and it works.


A site that has a stored XSS that can only be inflicted on a user's own account - a "self-XSS" - but that is also vulnerable to CSRF on the stored XSS injection point should be considered to have two problems: it is vulnerable to CSRF, and it is vulnerable to XSS. Closing the CSRF vector would mitigate that particular XSS risk, but both should be fixed.

"Stored XSS" doesn't require CSRF, however, Most of what gets termed Stored XSS is created by one user on a service to attack another user on the same service (so, same-site, not cross-site), and while victims could be directed to the infected page using a URL from outside the site (including cross-site links, iframes, etc.) they could also land on the infected page without the attacker sending them there at all.

For example, consider a social media worm. Somebody finds a way to inject script on a pubic social media post they create. The script looks up the friends of everybody who lands on the page and messages/tags all of them "hey, check this out". It also promotes the post itself with a "like" or "favorite" or whatever (it could also have some actually-harmful payload, beyond just spamming all your friends, of course). Thus, it could infect a huge number of users on the site - spreading through everybody's social graphs, plus infecting users who view this suddenly explosively-trending post - without ever having any cross-site element.

Getting back to CSRF + XSS, for the most part it's not really a meaningful combination. XSS (of any sort) allows making same-site authenticated requests, rendering CSRF irrelevant. Conversely, most CSRF attacks are to do the sort of thing an XSS payload would do, rather to inject an XSS payload (if there's a way to do that, you can usually just launch an XSS attack without needing to CSRF anybody). I suppose one could claim that most reflected XSS attacks are technically some form of CSRF - if you're attacking somebody by sending them to https://example.com/search?q=<XSS _payload>, you're arguably executing a CSRF against the search endpoint. However, searches are (usually) not state-changing, and thus are not considered a CSRF risk and don't require CSRF protection. The vulnerability in that scenario isn't that the search endpoint lacks CSRF protection, it's that the search query is reflected into the response without adequate encoding.


Is Firefox's new JavaScript support within PDF files a security concern?

Regular folks don't have to worry about this feature more than any other part of Firefox. For a professional worrier like myself (I literally get paid to worry) it's less concerning than JavaScript in a web page because of the lack of functionality.
JavaScript in PDFs has an extremely limited set of objects it can manipulate: just the form data. It can't access or manipulate the document text, nor does it have access to any DOM (browser) APIs and can't send network requests. In addition, Firefox has always opened PDF files in a special local context and it's no longer considered part of the site the file was downloaded from. We still show that original URL in the address bar for convenience (you might want to copy it, or manually edit it to a related URL) but it's pretty much a lie. Even if the script could get out of the sandbox through some security bug--and this sandbox has been in use for years with Web Extensions--it wouldn't be able to affect the site it was uploaded to.
The one new potential is that a jerk could write an infinite loop and try a denial of service attack, but that's not any different from any web page or framed web advertisement you browse to all day. It doesn't seem to be a problem in practice given equally "vulnerable" PDF viewers in Chrome, Edge, and Opera. You can always just close the tab as you would with a bad web page.
You can turn it off if you want with the pdfjs.enableScripting pref, but there's no real reason to do so.


Can hacker delete my server files and database where I am using below function?

To be awfully honest, this function is just an arbitrary collection of more or less useless or harmful and sometimes even contradicting procedures, most of which has nothing to do with security at all. Now to the most important part.

SQL Injection

  For prevent my website from sql injection i always use $db->real_esacpe_string()

Which is what you are doing wrong. You're not alone though, I list it as the most infamous PHP delusion. Citing from that page:

  this function has absolutely nothing to do with safety or injections, merely escaping special characters in SQL string literals, making them immune to SQL injection as a side effect, but being utterly useless for any other query part, from a table name to a numeric literal. To protect from SQL injection, one should follow two simple rules:

  Any variable data literal (i.e. a string or a number) should be substituted with a parameter, whereas actual value should be sent to the query separately, through bind/execute process.
  All other query parts that happen to be added through a variable, should be explicitly filtered through a hardcoded list of allowed values.

Given raw mysqli is rather tough with prepared statements, I would strictly suggest to use PDO instead.

So the main idea that nothing related to SQL security should be in such a function at all.

XSS

Let's see what are you doing with malicious < and > characters:

first, all tags get removed by strip_tags($text);
then these symbols (already extinct from the text) get replaced with an empty string
finally those non-existent characters get converted to HTML entities

If you ever ask me to define "overkill" I will just show you this function. htmlspecialchars() alone should be enough to prevent XSS in the page body.

What is more important, you seems to be using this function on the data input which is wrong. A text should be formatted right before the output, according to the formatting rules for the certain medium. If you're outputting into HTML page body, it would be htmlspecialchars. It the text goes to JavaScript then it should be another formatting and so on.

Useless stuff

trim() has nothing to do with security at all, you could use this function for convenience.

on a side note, never even use this @ operator. It is harmful for your programming experience.

stripslashes() as well, has nothing to do with security. Besides, this function is just useless, never doing anything sensible at all.
Not to mention that get_magic_quotes_gpc() is twice useless, returning a value that has been removed from PHP 10 years ago.

Conclusion

get rid of this function
to prevent SQL injection follow 2 rules from above
to prevent XSS use htmlspecialchars when outputting your data or any other appropriate formatting.


How to root a virtual device in android-sdk?

In the emulator which you run as part of Android SDK, the adb has root permissions. That is, it can run with UID as 0. Check it with, adb shell id or whoami. If it is not root, run su in the shell which will give you root access.
In some custom images like Lineage you can start adb with su permissions by using adb root.


You ask numerous questions, so I'll try to address a few of them.

First, the question posed by the title, "What exactly are the keys doing in a Certificate?"
They're doing nothing, because they are not there. The key-related stuff in an X.509 Certificate is just a hash of the public key to which the Certificate applies.

"how exactly do the parts of a cipher suite work?"
The specified symmetric cipher will be used, with randomly generated per-session keys, to encrypt the data streams. The specified asymmetric or Public Key cipher will be used to establish the session, including exchanging keys to be used for the symmetric cipher. Both ends of the connection have to agree to use the same cipher suite.

"How exactly do these keys work to be applied to encrypting/decrypting messages"
The exchanged keys, which have been randomly generated for this session only, are used with the symmetric cipher to encrypt and decrypt the data streams.

"What is the difference between public and private keys"
From just the Public key it is not possible (or, it is computationally infeasible) to derive the Private key. Thus, you can make your Public key, well, public. Details of just how Private/Public key pairs are generated is specific to each Public Key algorithm.

"how is this different than using just the symmetric key for symmetric algorithms?"
Public Key algorithms are generally slower than symmetric algorithms, but they win in the key-distribution stakes: To exchange symmetrically-encrypted messages pairwise between N parties, where each message is readable only by its intended recipient, requires O(N^2) keys - each party needs to distribute different keys to each of the other (N-1) parties. To achieve the same result using an asymmetric cipher requires just N Private/Public key pairs - each party publishes its own Public key, and keeps its own Private key secret.


How to secure clear text data that is transmitted through LAN / Wireless LAN connection and PPTP VPN without a domain name (IP address only)

Go for HTTPS.

All else aside, your VPN is likely not terminating on your Odoo, so it would potentially be possible to sniff the credentials as they transit between the system running your VPN server, and the one running Odoo.

Implementing HTTPS would ensure the communication (and credentials) are encrypted up to the Odoo server.

As a starting point, you can generate a self-signed cert using openssl with:

openssl req -newkey rsa:2048 -keyout server.key -out server.pem -subj "/CN=myserver/O=myCorp"

You could also look into something like cfssl (https://github.com/cloudflare/cfssl) to generate a 'proper' PKI with a CA and server/client certs.

In all honesty, FQDN would be nice (and you could make it easy by editing your /etc/hosts, or system-specific equivalent), but isn't required.
You can, all else aside, add IP addresses to certificates (as a SAN - Subject Alternative Name) that would be considered 'valid'.

The main issue is that unless you import your CA chain into your browser/device cert store, you will still get warnings about self-signed certs.
You should try and avoid that - getting people used to ignoring security warnings is a Bad Thing ©.

It sounds like you would be better off using your VPN for routing purposes only (basically, so that you can always speak to your system at the same RFC1918 address), and avoid exposing all this to the internet at wide until you know you have everything nice and locked down.


What is the best way to restrict /proc fs from malicious users (linux)?

In general, hidepid mentioned in the comments is the best way.

If you need more security than that, use a mandatory access control system like SELinux or AppArmor, and possibly systrace. These tools let you restrict file system access, syscalls and more. I think most of the info in /proc is not available from syscalls, but I'm not up-to-date on this.

MAC tools are not "click and go" solutions and require quite a lot of work to configure. Before you embark on this, have a think about whether this is the best way to invest your security resources.


There is a recommanded solution to protect SRP verifier to be used if the DB is leaked?

As with databases of password hashes, the traditional approach to prevent dictionary based attacks is to make computing hashes (or in this case verifiers) from passwords costly enough.

In the case of SRP, the obvious way to do this is to choose a group which is large enough. (In any case, it must be large enough to resist cryptanalysis, as with RSA or DH.)

Obviously, increasing the size of the group will also slow down both clients and servers.

Another possibility is to replace SHA-1 with another hash function as is suggested in section 3.2 of RFC 2945. The salted SHA-1 construct used in SRP-SHA1 can be replaced by another message digest, or by HMAC or by a password hashing function.

In my opinion, using a good password hashing function such as Argon2 or BCrypt or PBKDF2 instead of SHA-1 makes sense. Doing this increase the cost of dictionary attacks without having any impact on server performance. (Client performance is impacted though.) On the other hand, this does not improve resistance to cryptanalysis.

SRP is designed to protect passwords in a threat model which assumes an attacker can gain access to the memory of the server. Thus, SRP is designed to be secure in a context where an attacker would have access to your master password.

This above also means SRP actually competes with password managers, the later being a more widely deployed solution. SRP is mostly useless if your users already use password managers with a unique password for each site.

Encrypting stored verifiers is essentially the same as "peppering" a password database. This adds quite a lot of complexity. Whether this improves the security of the system is not obvious.

This only makes sense if you assume the attacker has access to the database but not to the server (while using SRP only makes sense if you assume the attacker has access to the server), your master password has good entropy and your encryption code is properly written (IVs are properly generated...)

Regarding your usage of Argons2, you should make the parameters fixed: use as much memory and processing power as you can afford. Do not make the parameters depend on the password.


Yes, git-credential-cache has the built-in functionality to read the cache contents, you just need to run this command to obtain the stored credentials, including password in plain-text:

$ echo -ne 'username=<repo_user>\nprotocol=<repo_protocol>\nhost=<repo_host>\n' | git credential-cache get

For instance, if you are using https://git@github.com as your repository, you could extract stored credentials by doing this:

$ echo -ne 'username=git\nprotocol=https\nhost=github.com\n' | git credential-cache get
  username=your_github_user
  password=your_github_password_in_plaintext

The "username" part in the query is only required if you have more than one user working on the same repository (which I guess is your situation).


A server generally isn't configured to only support one version. The server can be configured to accept all versions, even lower stuff like SSLv3. During the initial connection between the client and server, they will negotiate and determine the highest protocol version they both support.

That being said, if a server only accepts 1.2 and the client only knows 1.0, they will not be able to negotiate a connection.


Facebook mobile app is often asking about my phone number for registeration, field is entered already. Where does facebook take this phone numbers?

If any of your friends have shared their contact details with Facebook, they may well have picked it up from there. It's buried in the terms and conditions that they have on account creation, so it's very easy to miss...


Fuzzing is not a technique to find known vulnerabilities. That is the job of an active security scanner like you said. Instead, a fuzzer is designed to assist with finding new bugs that are not yet known. They do this by constructing random or pseudorandom input and feeding it to the target. Good fuzzers will be format-aware and will feed it input that appears slightly corrupt, but is otherwise valid. When this is done for long enough, new and unknown bugs will often start to surface. These bugs can be analyzed and sometimes even turned into a working exploit.


Antivirus detection of where exe is compiled

Try PEStudio. It will cut and gut your individual EXE and then rank the individual parts on VirusTotal. Very interesting.

We'd need a sample EXE to tell you more.

https://blog.malwarebytes.com/threat-analysis/2014/05/five-pe-analysis-tools-worth-looking-at/


How practical is a certificate's "basic constraint" property in protecting my HTTPS / SSL session?

Up to a few years ago (something like 2003 or 2004, if I remember correctly), Internet Explorer was not verifying the "Basic Constraints" extension. When this was discovered, Microsoft promptly published a patch.

On a general basis, the "Basic Constraints" extension is properly verified by all existing validators. Internet Explorer was really the worst student in the class on that matter. It is called "basic" for a reason: it is the simplest X.509 extension to handle.

You protect yourself against badly configured CA by ceasing to trust the relevant trust anchors, and sending lawyers to punish such misbehaviour.


Should crash dumps (e.g. from Breakpad, Windows) be encrypted and signed?

Dumps give too much info for hackers to reverse engineer or hack the software, say to enable features or licenses?

The dumps must, at some point, exist in unencrypted form. An attacker with full local control can either grab the dumps at that instant - or simply ignore them, and look at the memory of the running application at will.

Some programs, such as spotify, try to detect if they are running in a debugging environment, and use various obfuscation schemes to slow down reverse engineering. This may thwart un-experienced attackers, or slow down experienced ones. But it will probably not stop an attacker. This is basically the reason why companies like Microsoft opt for online license validation.

However, encryption in transit is an entirely different matter. Protecting customers assets that may be available in a dump, or even licenses installed on a customers computer, makes this a good proposition - ensuring that no third party can get access to the dump.

It's also easy to implement; submit the dump over for instance https. While the gain from this may be small, depending on the content of the dumps, it's also very cheap to implement, and reduces the risks to both yours and the customers data. Remember that your customer probably values their data more than they value your product.

  A user could return us a maliciously malformed dump, which causes havoc when we try to decipher the dump on our machines. If our application signs the dump, at least we can confidently open the file.

To sign the files, the application has to access a private key. The private key has to be present in memory on the machine doing the signing at some stage. It has to be distributed with every instance of the software.

An attacker can access the key and sign his malicious dump file.

It will not help against using the dumps as an attack vector.


Is server side CORS protection enough to mitigate CSRF attacks against stateless APIs?

A CORS policy is not sufficient to protect against CSRF attacks in general, but might be in this specific case.
The question is, if the API accepts "simple" request as defined by the CORS specification. These are requests which can be triggered without JavaScript, i.e. by a form upload, embedding an image or similar. In this case the request will be send directly to the server and all what CORS could prevent is that the attacker could read the response. This is thus not sufficient to prevent CSRF, since CSRF about writing the request and thus executing the action at the server.
If the API instead accepts only non-simple requests (for example by requiring a custom HTTP header) then CORS will be a sufficient protection because in this case only a pre-flight request is needed before the actual request and based on the returned CORS policy from this pre-flight request the actual request will not be executed.


what is the cons and pros of using webfiltering based on cloud security?

Pros:

Possibly reduced cost. You won't be maintaining your own
infrastructure.
Cloud solutions typically allow you to force company assets (like laptops for example) to      be routed through the cloud proxy for URL filtering even when off network. (increased security)

Cons:

Could increase latency. This may or may not be applicable based on your location.
Less control over the infrastructure. With an internal solution you can disperse proxies over different locations and chain them together for increase response times.


Is it possible to prove a certain email has been sent using a certain computer?

Experts are experts. What an expert says stands in court as long as:

He is an expert.
The other party cannot provide another expert, who says that the first expert is wrong, and says it in a more convincingly expertish way.

In practice, a email will be reputed to have been sent from a given PC if the context makes it a lot more plausible than any alternative explanation. Context elements include IP addresses registered from the SMTP server side, ease (or lack thereof) to assume that IP address on the client side (WiFi or not WiFi, accessible wires...), presence or absence of log files on the PC... and, more often than not, whether the purported sender admits to the deed or not.

Take note that perjury is a serious offence, so people tend not to deny sending emails when what is at stake (e.g. a commercial dispute) is "less serious" than the consequences of being caught in the act of lying to the judge. The crucial point is that proving whether an email was really sent by some specific individual is a complex matter in both ways: it is hard to convincingly pinpoint on the perpetrator, but it is equally hard to make sure that it will never be decisively proven.

This reproduces the security model of handwritten signatures. It is, in fact, not very difficult to imitate the signature of somebody else; it is also quite hard to actually verify that a signature is proper or not. But handwritten signatures happen in the physical world, with pens and human hands, so they tend to leave traces -- what I call contextual elements. You can repudiate your own signature, but it is risky, because you cannot be sure that nobody saw you, or you did not leave a fingerprint on the pen, or any other of a million possible incriminating details. And trying to repudiate your own signature is severely punished. Therefore, it is often preferable to recognize the signature as your own and assume the consequences.

In the case of emails, the same mechanism is at work. Though actual proofs are often flimsy elements (log entries and so on), denying having sent an email that you did send is risky, and felt as risky, especially since it involves computers (computers are beyond the "magical horizon" of most people). So most cases involving emails end up with producing a few log file entries (that could, indeed, be faked in a great many ways), and the sender crumbling under the steady gaze of the judge.


Steps to Exploitation

Finding the Vulnerability

This is probably one of the hardest steps.  There are various ways to find vulnerabilities, and none of them are quick and easy.  This takes time normally on the order of months.  But lets say you're doing this on your own so you write your own bad piece of code:

  1 #include <stdio.h>
  2 #include <string.h>
  3
  4 int function(char **argv) {
  5     char buf[8];
  6
  7     strcpy(buf, argv[1]);
  8
  9     return 0;
 10 }
 11
 12 int main(int argc, char **argv) {
 13   return function(argv);
 14 }

So here the vulnerability is copying an arbitrary string from the command-line arguments.  Compile the code with stack mitigations turned off.

gcc overflow.c -o overflow -z execstack

Triggering the Vulnerability

Now you need to trigger the vulnerability.  You know what it is.  The strcpy blindly copies whatever string is contained in argv[1].  The buffer that the argument is copied into can only contain 8 bytes.  Anything past this will overflow the stack.  See this answer about how stack overflows work.  So you can trigger the vulnerability by running it like so:

./overflow 01234567ABCD1234

Now if you read the link on how stack overflows work you'll know that you've overwritten the saved stack frame pointer with 0x41424344 ("ABCD").  And you've overwritten the return address of the function with 0x31323334 ("1234").  This is great right?  You can now control the return address of a function which means you can now tell it where in the program to start executing.

This seems easy, but in reality triggering a vulnerability can be frustrating.  Determining the exact path can be straight forward depending on the resources at hand.  But nudging and poking execution to take the path that leads to a vulnerability to trigger it can be very difficult.

Exploiting the Vulnerability

You've triggered the vulnerability and the code segfaults.  Now what?  Now you need to write your shellcode to do something useful.  This is purely up to you.  Writing shellcode is an art in itself, but exploitation comes down to being able to write your shellcode into memory, and then executing it.

Back to our example.  We're overwriting the stack.  So keep on writing!  After the return address is overwritten write your shellcode onto the stack.  So now you have something like:

./overflow 01234567ABCD1234<SHELLCODE>

Remember how memory is oriented, and make sure the shellcode is aligned to the stack.  You know the size of your shellcode.  We're working in an example where program memory is not randomized so we know the address that we overwrite (You can find this by running your program in gdb and witnessing the address for yourself).  With the address and the size you can calculate the address at which your shellcode starts.  Rather than using 0x31323334 use 0x<address of shellcode>.

Now you have something like: ./overflow 01234567ABCD<address of shellcode><SHELLCODE>

The function will return to your shellcode, and begin execution.

Reality

That was fun, but in reality there are a lot of things you need to take into account.

Stack Execution

The program was compiled so that the stack was executable.  In reality it might not be if DEP is turned on.  This is where return oriented programming comes into play.  ROPs help execute portions of code at a time in executable portions of memory.  Generally a ROP's job is execute instructions that will mark the area of memory the shellcode is in to executable, and then jump to the shellcode.

ASLR

ASLR will randomize the address that a program is executed or a library is loaded.  You can see how this works by running the piece of code in the previous link.  You'll be able to see how each time a program is run the address changes.  This means you can't rely on that pre-calculated address.  Generally you'll need a separate vulnerability to leak an address or get the address of a library in order to calculate where you are running in memory.

Stack Overflow

In a stack overflow you just blew away the stack!!  You possibly overwrote other return addresses, and key pieces of memory that the program needs to run.  Yes the shellcode was run, but what do you do when your shellcode is finished?  Cleaning up the stack correctly, or closing the program gracefully is another challenge.  Or maybe you just don't care, because now you full access to their box anyway.  Just something to keep in mind.

Lots of ways to skin a cat

Gaining execution can occur in lots of different ways.  This post only goes over the one example.  As you begin to grasp these concepts you can start to get into other techniques for gaining execution after triggering a vulnerability.  But that would be well outside the scope of this answer.

I'm sure I'm missing something in all of this. At least this will give you an idea of how difficult exploitation is, and how much you need to take into consideration.  Hopefully you can use this as a base, and perhaps later if you have more questions you can ask a more specific question.


Can an old fashioned crypt encrypted file be brute forced, if so how?

The usual way of cracking an encrypted file is trying different keys until you get a result which makes sense. How do you know you found such a result?  Usually because you know the resulting file must have some kind of internal structure. For example, when you know the decrypted file is in an XML format, you would run every result through an XML validator. Or when you know the decrypted file has its own checksum somewhere, you would check if it matches. When you expect natural language text, you could check the letter frequency to be similar to natural language.  On UNIX systems you have the tool file which can detect many common file formats. When it returns something, it might be a possible hit.

But when you have no idea at all what might be the content of the file, you have no way to tell if the garbage returned by applying the algorithm with a random key is in fact the garbage you are looking for.


Can a Bettercap show all the WIFIs around?

Yes, Bettercap can show you all the wireless Access Points in range.

The reason why you didn't see all of them (or any) depends largely on your hardware and on your exact configuration.

What is Monitor Mode?

When you put your wireless card into monitor mode, you tell it to forward every packet that it receives to the operating system and to any application that wants to receive them. This includes packets of an access point that you did not associate with (aka. "logged in").

This allows you to see everything that is going on around you, on the frequency you listen to.

What is a Channel?

While Wi-Fi operates on radio frequencies, people often don't speak about exact frequencies. Instead, they speak about channels. These channels define a frequency band, which is used to transmit data.

If lots of Access Points are configured to communicate on the same channel, then a lot of noise is generated and the quality of the signal will be worse.

In order to see all the Access Points around you, you need to listen on every channel. Since this isn't possible, you need to "hop" from one channel to the next - just like a radio when looking for stations. This means first you set your card to listen on channel 1, then on channel 2, then on channel 3, etc.

If you want, you can also include the 5GHz channels, which would allow your card to listen to both 2.4GHz and 5GHz traffic.


How do I use crlDistributionPoints with keytool?

Guessing here:
Use raw OID 2.5.29.31 with the generic -ext parameter.

But like Crypt32 said: This is terrible to manage.


How to implement client side encryption for CalDav & CardDav content?

No, this is impossible.

For CalDAV and CardDAV to work the server needs to be able to see the contents of the file in order to respond to the WebDAV/CalDAV/CardDAV methods REPORT and PROPFIND and similar.


MASVS 1.12: "Endpoints verify that clients use up-to-date version"

After talking to some of the authors of the OWASP MASVS document on their slack channel I think the answer boils down to:

It doesn't matter if this check is done client-side or server-side
Its goal simpy is to be able to force users to update off of old versions.
An attacker attacking the app could circumvent/beat this version check in many different ways independent of whether the check is done client-side or server-side.


Convert PDF to plain text, remove malware?

As soon as you open the pdf to copy its contents and if there is any exploit present then it is going to be executed if your pdf reader is vulnerable to arbitrary code execution vulnerability and then it will infect all your files or just open up a backdoor.

If you want to open such pdf files create a virtual machine using vmware workstation put the pdf in a virtual machine and open it with updated pdf reader like adobe reader then you can copy and paste the contents of pdf file in a guest machine (virtual machine) to a text file in a host machine.

If you copy the (text) contents of pdf into a txt file then the malware won't work.


Will sabotaging a shared web hosting account threaten the security of sibling accounts being that they are shared on the same server?

It depends on the degree of isolation between accounts. Simplifying what would otherwise be a quite broad topic:

No isolation worth the name

The webserver runs as, say, wwwrun:wwwdata, all the websites are group readwritable, accounts are ftp-chrooted into their own webroots. A malicious script on site A is then running as group wwwdata, and may read and write files on other webroots. You could say that such accounts are born compromised.

Still, some small firms that maintain websites for customers (complete outsourcing) might choose to operate this way, since "we're the only ones to access the server". Poor maintenance, disgruntled employees and installation of vulnerable third-party frameworks, usually not in this order, are the main risks. I.e. if customer A wants to not upgrade a heavily firm-customised version of MyNiceBlog 1.0 to security-fixed 1.5 because porting the customizations would be expensive, he's actually endangering all the other sites on the same machine.

Minimum isolation

The webserver runs as above but there are limitations ("safe modes") that try preventing a script from exiting its web jail. The problem is that the process is voluntarily refraining from using some of the rights and powers that it still has. So you need also to remove some functions and features (e.g. executing a shell script) which could lead a malicious script to being able to use again those powers. The site is only marginally more secure, and loses several features and performances in the bargain.

Reasonable isolation

The webserver runs with full permissions, then for each request it receives, it spawns a copy of itself with reduced permissions. Each webroot is then also owned by a specific user with a group of his own, and there is no cross-read access. The user is chrooted into the web site.
If everything works as it should, this setup is reasonably secure -- so you must be wary of privilege escalation exploits that might make thing work as they shouldn't. Depending on the platform and software installed, the attack surface may be quite large. Some functions (e.g. loading dynamic modules) might still require blocking.

Also, the processes are not isolated at the network level; so for example any request from site A would be seen from site B as coming from the same host, which can be bad for (say) database servers. If site A has a GRANT ALL PRIVILEGES ON mydb.* TO root@localhost, site B may connect to that database on the same "localhost" with full access and A none the wiser.

Strong isolation

Each webserver instance runs in what amounts to a virtual machine of its own, with independent networking. The sites can't see each other and, if they do, they do so with external IP addresses, so DB server A can't mistake a login request from site B for a request from inside itself. Still, resource contention might be an issue, and connections to the outside might be NATted so that they are indistinguishable. Site A might then send emails pretending to be site B, for example, or it could try and reclaim all available memory, bandwidth or disk I/O slots to negatively affect site A. Some low-level functions might be shared between machines and can be used to mount attacks, e.g. clock and randomness-source reading to defeat authentication schemes.


How can I minimize the effects of data brokerage?

You made the link when you changed the e-mail addresses...

A way to avoid this is to use a third e-mail address in between the process. That is, me@bigprovider.com to me@thirdpartyprovider.com to me@smallprovider.com.
Or in other words, use some indirection (from one to as many as you want).

The thirdpartyprovider.com should be service that you trust enough (or could be your own server :).
As you describe, bigprovider.com will get a notification when you do the first change, and then thirdpartyprovider.com when you do the second (and final) change.
Assuming you eventually get rid off of thirdpartyprovider.com or you trust that service enough not to leak any data, the bigprovider.com will not learn the transitive set of relationships: me@bigprovider.com to me@thirdpartyprovider.com to me@smallprovider.com.

If you use different thirdpartyprovider.com for each business/websites you work with... you make more difficult such aggregation of data if there is some data leakage at any of them.

In any case, the online merchant will still learn everything, all the changes. But there is no way to avoid that (not in your scenario at least).


How does Chromium's sandboxing compare to Firejail's?

The browsers do not allow application to directly access the filesystem. They can only:

Ask the user to upload a file of their choosing.
Start downloading a file that will be safe in the directory chosen by the user (by default the "Downloads" directory).

Installed applications can have a full access to the filesystem.
On top of that, further restrictions can be added by Firejail or Apparmor to limit the access to the filesystem (among other resources). Those restriction can be applied to any applications, including browsers. So instead of choosing between a Chromium sandbox and a Firejail sandbox, you can use both.


Can a compromised mobile phone be used to penetrate a desktop or server?

Yes

When you plug into USB, you can do a lot. The link above is about using your phone as a USB keyboard, which means you can run commands, download and execute software, etc.


Kerberos vs. LDAP for authentication -- which one is more secure

Can anyone describe/outline the relative merits of using Kerberos or LDAP for authentication in a large heterogeneous environment?

LDAP authentication is centralized authentication, meaning you have to login with every service, but if you change your password it changes everywhere.

Kerberos is single sign-on (SSO), meaning you login once and get a token and don't need to login to other services.

There's a trade-off: LDAP is less convenient but simpler. Kerberos is more convenient but more complex. Secure things are simple and convenient.

There's no right answer. If you need SSO use Kerberos. Else LDAP. You could also consider YP/NIS (over IPSEC) for centralized authn.

The fact that the OpenBSD security hawks dropped Kerberos but make their own LDAP server might tell you something...

  Can we switch between them transparently?

No, you cannot. Well, maybe you can with PAM. But your users will notice


Way to keep Google from knowing the SIM card I am using on Android

In order for Android to make phone calls the OS has to be able to access the SIM details. It has to know what provider the sim belongs to in order to connect to that provider's towers. As google has written Android they can theoretically suck all the details they want off of it, and the only step you could take to prevent it would be to block your phone from accessing the internet. That would limit the usefulness of your phone dramatically of course.

If you're paranoid the option is there to write your own fork of android which would prevent it from sending data to google, which would be a very big project. It's possible someone has already done this.


EMV(Chip) Cards - What's the point of having the chip card communicating directly to the authorising server? & Clarification of CDA in EMV

In answer to:

  What's the difference between having the card talk to the server directly and having the card tell the point of sale system its details and then communicating with the authorizing server (Which can be done by a magnetic strip or proximity card)?

The difference is that end-to-end encryption (also called point-to-point-encryption or P2PE in the payments industry) means that anyone between the card and the issuer is kept in the dark about the sensitive details of the transaction (PAN etc.).

As for:

  What are the benefits of this procedure that EMV cards have then? and why is it necessary (if it is)?

The benefit is that you don't need to trust anyone between the card and the issuer. In the case of POS malware the advantage here is obvious. But this also has advantages even if there isn't any malware along the path between card and issuer.

If the merchant can't see the card details then the merchant can't store the card details. If the merchant can't store the card details it narrows the scope of PCI-DSS audits and reduces risk for the merchant. And for processors who route the transactions. And anyone else between the card and the issuer.

The PR answer from organizations in the apyments industry is that this makes everything safer for everyone. A more cynical answer is that the merchant would rather pay a bit more now for a P2PE solution to prevent expensive investigations, fines and settlements later.

Your question and my answer deal with encrypting the sensitive information between the card and the issuer but P2PE is something that grew out of EMV cards. It's an extra security measure made possible by EMV cards (and other 'intelligent' media). A mag-stripe card is a dumb medium and not being able to implement P2PE is just one drawback.

As for your question about DDA and CDA I'm afraid I can't provide a better answer than the simplified answers you can find on Google etc.


Does ssh-agent store the SSH key passwords in cleartext in the memory?

You asked about if ssh-agent stores the key passwords in cleartext. I think from looking at the code we would probably find that it doesn't store the passphrase used to decrypt it but does store the decrypted key that is then used to establish an SSH connection.

But there's a more important issue in point. If an attacker has access to your system memory (RAM), installing for example a keylogger or some other RAT malware would be trivial.

You have clarified your question to ask if it's necessary to password protect your private key when you have full-disk encryption. I would argue yes it is, because full-disk encryption is a protection against offline attacks. Once you're booted into your system, any attack which compromises your running system (most likely with your user credentials through a web browser exploit) would be able to read your private key file. If the key file is encrypted, then you have averted this threat.

If you have encrypted your private key, and the attacker gains access to your live system while the private key is in memory, they would now have to use privilege escalation exploits to gain the ability to read those keys in memory. These techniques get complicated when you consider they would need to figure out exactly where the key in memory existed, else make your Internet connection upload your entire memory pool - something you are likely to notice.


Is it possible to breach prepared statement and stored procedures with unsafe sql query string

Unless you are doing some dynamic SQL inside someProcedure or not using mysqli_multi_query() you should be safe at this point but since you are not escaping or validating user input, and if $unsafeString is stored in a database, an attacker can use this at a later time and it would be difficult to spot. Therefore I would change to prepared statements everywhere in your code so you handle all the data, even one stored in the database safely.

EDIT:

CLARIFICATION

Depending on how you handle data in you application, and since there is obliviously a place in the code where you don't use prepared statements it would be safe to assume there are other places where you might not use it either. If for example you handle data previously stored with a call to

$query = "call someProcedure(?,?,{$unsafeString})";

there is a possibility you are handling that string in an unsafe manner where code injected into the data could be executed. For example, concatenating the data with a SELECT statement. This kind of vulnerability is difficult to spot since you might assume data already stored in the database is safe.

Also, by not escaping or validating the input, you are opening yourself to a XSS attack depending, of course on how you handle that data later or.


What processes would indicate my computer is infected with malware?

Just eyeballing task manager is a bit hit-and-miss, unless you are very familiar with what normally runs on your system. In general, though, I look for:

Process names which are just a jumble of random characters or numbers
are often a sign that they may be malicious, but shouldn't be
used as a definitive indication.
Misspelled names of common processes.

But it's much easier to use other tools, such as using Sysinternals Process Explorer for a deeper look, which includes VirusTotal integration (So you can right-click on a suspicious process and click "Submit to VirusTotal"), which will submit the hash of the file and return the VT score if it has been seen before.

Also keep in mind that not all malware runs as its own process. As an example, some malware may be injected into usually-trusted processes such as explorer.exe or svchost.exe.

It's really less about spotting malware and more a matter of knowing what is normal for your system and investigating anything strange.


Why can't you and how to take a picture from infected computer?

I would recommend downloading a live Linux distribution (Ubuntu is great for this), create a bootable USB device on a clean computer, and booting your infected computer with this USB drive.

With Linux running, you can copy all pictures to another USB drive, without any Windows malware interfering.

Virus attaching themselves to PNG files are very unusual. Infected PNG files are usually made by hand, not something that gets executed and goes infecting other PNG files.

You don't have to, but if you want to really be sure, open the file manager on Linux, right click on each image, Open With GIMP (or any other image editor on the distribution you are using), save the file in another format, like JPG. But I really don't think you will need to do this.

Now, your methods:

  Plug in USB and copy the picture.

Some malware can copy themselves to any plugged USB drive, and create a copy of itself with the picture of a folder. Opening this "folder" infects the next computer. Other ones rely on bugs to infect the computer when a link is seen (not opened) on Windows Explorer. Improbable, but possible.

  Go to Starbucks, connect to wifi and put the picture on cloud storage

You don't need to go to Starbucks, you can use your own network connection. And I don't think Google/Dropbox/Microsoft would scan a PNG file for you.

  Look at the hex of the image...

What? That would mean typing an encyclopedia by hand... Better pay someone to paint the picture to you on canvas, by hand. It would be faster...


Why does my bank bother asking basic personal questions to log in to online banking?

I agree that this is bad practice. You can make it better practice by scrambling the answers in one of many ways -- making questions about your father refer to your first car and vice versa, and so on, or giving false answers, or given IRRELEVANT answers (if you can remember what your irrelevant answers were), would discourage/prevent social engineering attacks. There's nothing in their system which requires that you answer these honestly, just consistently.

Some systems will let you enter your own questions, which is a huge improvement since it encourages picking things that act as more-secure passwords.

However... I've only seen these used to secure one specific operation, that being password reset, which is additionally handshaked (handshook? checked, anyway) by interaction with the account owner's mailbox. Of course the mailbox may also have been cracked, but arguably this is a case of two less-secure mechanisms adding up to one that's almost tolerable.

It's still worth complaining to your bank, though. If enough people complain, they may improve it.


This is a design flaw in csh, allowing the evaluation of backtick escape in the contents of environment variable.

Overall, the assumption is generally made that controlling the environment of a shell should not lead to execution of arbitrary code.

Breaking this assumption creates dozens of attack vectors for remote code execution, from CGI scripts to malicious DHCP replies to mail forwarding.

When this behaviour was accidentally triggerable for bash, we called it Shellshock and made a huge fuss about it.


Can a heap/mmap buffer overflow overwrite the stack

In theory, because the heap grows up and the stack grows down, maybe it could be possible if both were to grow far enough. However, in practice, it's very unlikely.
There is generally a large, unmapped range of memory between the heap and the stack, and there may be other regions mapped before the stack for shared libraries and such. The problem is, the moment you try to write to an unmapped address or a read-only page, you will trigger a segfault. This will certainly be the limiting factor if you attempt something like this. The same applies to your second question. Unless the memory region is directly adjacent to the stack with no gaps, you will probably have trouble.


Yes - if the malware included a keylogger, for example, it could simply read the master password when you typed it in. The only real way to prevent that would be to have KeePass be the only software running, on a verified secure computer (e.g. no hardware keyloggers, no VMs, etc.) which would somewhat defeat the purpose of having passwords to hand.

However, the same malware would also be able to read the master password for a cloud based database, when you opened it. It's not specific to local database files. In fact, it could take a less invasive piece of malware to do that - if you've installed a dodgy browser extension and view your passwords through a web site, it would be able to see what you typed in the browser, but (probably) not what you typed into any other program.

If you're using a system which has malware on, assume it can do anything you can do - if you can read a file, so can the malware. If you can contact a specific server, so can the malware. If you can disable your AV software, so can the malware. It might need to get details off you in order to do it (e.g. passwords), but the key is to avoid getting it on the system, rather than trying to ensure that every single piece of software detects the presence of it.


Do I need to decode a base64 representation of a key?

Encoding 128 bit random data as base64 results in 170 byte not so random data. Since the method you want to use requires 128 bit random data you cannot use the base64 encoded version but must decode it back to the 128 bit version.


There is no perfect way to ensure that a program is not malicious, short of extensive reverse engineering. Even with access to the source code, you would need to audit it pretty heavily. While major projects often do get such audits, it is not a panacea. The best you can do is threat reduction.

Does not send any USB data to an external server without my knowledge

This can be mitigated by enabling firewall rules that limit or outright prevent sending traffic over the network for the user that the analyzer is running as. You could also run the analysis on an airgapped computer with no connectivity to the internet.

Does not install any key loggers or other malware like software

While antivirus can detect some simple threats, it is easy to get around it. You could either run from a read-only live DVD, or use Mandatory Access Controls. This technique is similar in purpose to a security-oriented sandbox. MIC is a MAC for Windows, and AppContainer is a sandbox-like isolation feature for Windows. Linux and related operating systems have even more extensive isolation.

Does not screw up my computer. This is what I'm worried about more than anything. For example, I read that another USB debugging tool blocked all USB traffic including mouse/keyboard and rendered the computer useless until the user rolled back their version of Windows.

While you may be able to reduce the chance of software being malicious, knowing how bugs in it may interact with bugs in your operating system is even harder. A potential way to reduce this risk is to use USB packet capturing software and analyze the actual packet dumps using a separate, unprivileged program, allowing you to segment the privileges required to complete your task.

Edit: this is a broader question to related to how one may validate a piece of software when that software's source code is not available. I realise that a certificate helps, but even then, a certificate doesn't guarantee that a piece of software is not doing sneaky things.

There are a few things you can do to reduce the risks:

Use open source software, ideally popular software that is well-audited.
Only use signed software, and verify them using programs such as GnuPG.
If you are particularly paranoid, only use software with reproducible builds.

On Linux, you can use the usbmon kernel driver to capture raw USB traffic, then various packet analysis tools like Wireshark or Virtual USB Analyzer, both of which are open source. Using a well-known live Linux distro such as Knoppix will help reduce the chances that privileged software will cause significant harm to your installation, while preserving your ability to read and write to your disk and analyze captured USB traffic on the system. This gives you a few benefits:

The software required for USB protocol analysis is open source, making it easier to trust.
The software runs in a live environment, making it "amnesic", so changes vanish on reboot.
A Linux environment provides far more tools for debugging and low-level analysis than Windows.
All the mentioned tools are digitally signed, reducing the risk that they have been modified.


Why not generate a client SSL with expiration date in very distant future?

Because what is considered adequate security 10 years ago is not the case today (or we'd all be using SSL_RSA_EXPORT_WITH_RC4_40_MD5).
Because it makes CRLs umanageable - now we have OCSP for that but would require more frequent checking and moves the volume problem elsewhere.
Because it doesn't fit the business model of the encumbent certification authorities - if there was a (provably) perfect cipher suite their revenue stream would be destroyed.


Are there any real instances of threats to machine learning systems?

Yes, there are recent examples of attackers targetting ML systems in order to later evade detection. The term used for the study of this effect is "Adversarial Machine Learning". There are a number of papers:

Berkeley, 2010
Berkeley, 2011
IEEE, 2011

One of the techniques discussed is the "boiling frog" technique. Named after the effect that one can boil a live frog without it jumping away to safety if the heat is turned up slowly. Attacks using this method attempt to mistrain the ML system by introducing anomalous stimuli at a very low anomaly factor, but with high frequency. Over time, the anomaly factor increases until the ML system learns to ignore truly anomalous stimuli, at which point the actual attack on the target systems begin. Because the ML systems have been trained to ignore it, the attack goes undetected. (The same technique has been used for years against people and security guards).

This can be done with spam filters, IDS, UBA systems and Netflow analyzers.

For instance: if you have gained the credentials of a valuable user, and you want to be able to log in as that user during a time when that user does not normally log in, you can start logging in using those credentials at times only slightly different from the user's normal pattern while not performing any unusual activity. Once you have seeded the logs with enough logins around the time when you want to perform your malicious activity, you can make your attempt and know that you will not trigger alarms for the anomalous login time. By seeding the logs with non-malicious activity, secondary and tertiary analysis of the activity will support the decision that the activity is not anomalous.


Private exploits exist for many famous software out there, and the fact that a software is open-source, popular or many years old doesn't change a thing.

A vanilla Wordpress installation without additional modules is less likely to be exposed, but again, it is very possible that exploits exist for it.

Now, the question is more: does your friend have the technical skills needed to find this kind of vulnerabilities and exploit them?

Besides, asking him to "take down a well known website running WordPress" is a very bad idea, as this is illegal unless this website belongs to you or if you have a proper mandate to do so. If you want him to prove his point, you should install Wordpress on a server you own and authorize him to exploit it.


Does fetch() of an https: resource verify certificate chain?

There is some guidance:

https://fetch.spec.whatwg.org/#http-network-fetch

  The exact determination here is up to user agents for the time being.
  User agents are strongly encouraged to only succeed HTTPS connections with
  strong security properties and return network errors otherwise.
  Using the "deprecated" state value ought to be a temporary and last
  resort kind of option.


When encrypting password hashes, how to handle nonces?

Encryption is not the right tool for this job, since there's never a need to decrypt a hash. Use HMAC(k, PH(pass)) for some password hash PH in the set of argon2, scrypt, or bcrypt. This works as a verifier as well. You can alterntaively opt to do PH(HMAC(k, pass)) instead, but this doesn't ever allow for relief protocols where the client performs the slow hashing work The former also has the nice property where clients don't ever actually have to send you a cleartext password if you so wish.
If you do decide to encrypt password hashes, what's even the problem? You already have to store a salt, cost parameters, and the hash itself. What's one more thing?


A BFE registry key's ACL is flagged by Microsoft Attack Surface Analyzer - what do I need to do?

It says that this critical-for-security registry key is writeable by Local Service (S-1-5-19)    WRITE_DAC, which is a key security risk. Its ACL should be changed to administrator level group or users using the security tab for this key in regedit. Alternatively, you could simply remove this WRITE, as you never know what kind of integrity feature it is. With one bad ACL you can compromise the complete OS.


How can you enumerate an internal network with minimal outside knowledge?

Those are pretty solid ideas. However, I think you're overthinking this. I'd start with something like nmap, angry IP, or some other network scanner against internal (non-routable) address blocks. Zone transfer or scripting rDNS is also worth a shot. You can get a lot of info out of DNS.


Are logins with button pushes more secure than normal form logins?

You almost answered your question yourself, I might just try to give some grounds for why it is actually less secure than regular log in forms.

  Long story short, is this login method actually more secure? For me,
  it doesn't seem so, and it's so annoying given that it doesn't work
  with my password manager.

There is a rule, formulated in security.stackexchange:

  Security at the expense of usability comes at the expense of security.

See here.

Called: AviD's Rule of Usability, or how I call it - security through unusability. It basically means that as soon as you decrease the usability of the security measure, security itself will decrease. We can see many such "inventions" in software world:

disallowed "paste" in the password/username field - I have made fun of it in my tweet: https://twitter.com/m1ndas/status/789984433973628928 You can also read Troy Hunts blog post on that: https://www.troyhunt.com/the-cobra-effect-that-is-disabling/
crazy limitations on password length;
strict requirements on special symbols and simultaneous neglect on password length (incentive not to use long memorable passwords).


Videos and visual tutorials on Format String Vulnerabilities

The OWASP Testing Guide has some guidance, as well as some whitepapers and references to tools.

WASC has this entry.

There scanning tools that look for this kind of vulnerability. w3af has a formatString plug-in that might help you test, depending on your application's setup.

Other than these things, I assume you learned from the videos to test for printf formatting characters. If you add these characters to a dictionary and fuzzing attack on inputs, you can determine the vulnerability of the application, if not exploit the vulnerability.


The inherent risk in passwords are that users are bad at choosing good passwords, and tend to reuse passwords.  In a scenario like this, it sounds like your system generated password is never sent to the user.  You do not control their password on the facebook side.  You just care about authenticating with the Facebook system.  Your risks are significantly lower, unless you share your system generated password with the user, at which point all bets are off.

Following good security practices, you should still hash the passwords (never store them in clear text, unless there are valid technical reasons for you not to do so, or provided you have some other compensating controls in place to protect those passwords), and change them regularly.  You should have a mechanism to generate fresh tokens with Facebook, so maybe schedule a process to do it automatically every 30 days or so...


Short answer: yes.

Longer answer: You should have CSRF protection EVERYWHERE where you do something which requires the permission of the current logged in user and is changing some data.


DOMXSS - Is Input Field Content an Attack Vector?

That would be hard to exploit without combining it with another vulnerability. How would the exploit code get into the input? I suppose combining it with UI-redressing or something like that could have worked, but I dont see any clear way of exploiting it. Could be seen as a self-XSS.


Is there such a thing as an SSLeay/PKCS#1-style static Diffie-Hellman key?

Short version:

Yes, PKCS#8 is a PKCS#1 style wrapper which can contain a DH key.
PKCS#1 is an RSA-specific format, so no, you won't find a DH key in it.

Medium version:

Once upon a time, RSA invented some crypto.  And they wanted to wrap it in a usable format, so they invented PKCS#1.  That's why it's, you know, #1 - because it came first.  But it really only handled RSA keys, as reflected by the use of "RSA" in the wrapper.

Somewhat further along the road, they said "Wait a minute!  We should be able to do the same thing with DH keys, and Elliptic Curve keys, and...  Let's create a new PKCS that's flexible by design and can handle different types of keys.  And, um, while we're doing it, let's take the algorithm name OUT of the wrapper and encode it as part of the data."  And that's how PKCS#8 was born.

Long version:

There's a question on Stack Overflow that triggered some great answers in this space.  This answer talks about the PKCS#1 / PKCS#8 distinction.  And this answer, which is bear-like in its awesomeness, goes into the details of the design history that I've tried to sum up in the Medium version above.

Footnote: the "Long version" I've provided is actually longer once you've read the two referenced SO answers, so don't be snarky.


Creating a separate privileged (admin) user account for authenticated VA scans

Let me see if I understand your question. You want to enter the live, admin password into an automated tool? And you are unclear on the risks of doing that?
A few things come to mind:

the distribution and storage of the live admin password across multiple "users"
the sharing of an admin password for multiple purposes
the lack of positive attribution of any actions performed to the scanner or the admin
the inability to easily disable the admin password if the scanning tool is compromised
the inability to lock out the scanner's credentials outside of expected scanning windows
the inability to limit the scope of the scanning admin account
the violation of "principle of least privilege" and "separation of duties"
the various compliance issues that might arise

The scanning account needs to be distinct to each scanner so that its effects can be limited, the actions of the scanner can be properly attributed, and the credentials can be disabled if compromised.
No one should know the system/domain admin password but the admin...


If it only prevents page/script from reading the response from another origin, can't we just use a proxy listener like Burp or a sniffer like wireshark to capture the response before it even reaches the browser (where SOP is implemented)?

These are two different types of attack. Preventing reads from another origin prevents an attacker's site (evil.example.com) that the user has visited from making an XHR request to the site that the user is logged into (webmail.example.com) and getting the data. In this case it is stopping other websites from reading the user's email messages.
If you can configure the user's machine to use an intercepting proxy or if you can position Wireshark listening on promiscuous mode on the user's network then it is likely that as the attacker, you do not need a cross domain XHR request - you could just observe normal traffic. An exception to this is in the case of attacks such as POODLE. For example, if you could listen to traffic over the network, but the user's connection is made to the website using SSL, you may need to inject XHR traffic as a MITM in order to decrypt one byte at a time via the POODLE attack vector.
The Same Origin Policy does not help here, but if it did not exist there would be no need for the MITM attack nor the POODLE vector. The Same Origin Policy defends against some web based attacks that would otherwise be possible, nothing more.

Why does the server even respond to such requests from another origin? Shouldn't they only respond when Cross-origin resource sharing (CORS) is enabled on them?

Yes, it would be a hell of a lot more secure if servers only responded to requests from their own origins. However, this would break most of the internet if it was implemented as standard in new web server releases. It would also be possible to create a browser that did not make cross origin requests. Nobody will use it because it will not work on many sites.
You can in fact disable 3rd party cookies in most browsers. This would in effect make cross origin AJAX requests anonymous, as no cookies would ever be sent. Certainly Chrome will prevent setting or reading cookies, other browsers may only restrict the setting of such cookies. Of course if another authentication method is used, such as basic HTTP auth, it can't help you here. However, if you try it, for the most part you will be able to see which functionality breaks.

Why does the server even respond to such requests from another origin?

The Origin browser header is not read until headers are parsed, and at that point the browser has already sent cookies across - any restriction on cross origin would be better implemented at browser level because a web server will not be able to block the request before it is sent.
Allowing cross origin requests is the way things have worked historically and security needs to be balanced with compatibility. CORS has been designed in such as way that if the server does not opt into CORS, the security level is just the same as using a pre-CORS browser. Before CORS it was possible for sites to make requests to other domains via forms or resource requests (but not via XHR), and it is the same now. If you think about it from the server's perspective, an XHR GET request is just the same as including an image from another domain using an <img /> tag. An XHR POST request is just the same as creating a form that submits to another domain.
You could configure your server to block these requests (say using the Origin header), and this is actually a valid way of preventing CSRF attacks. This should be done on a case-by-case basis though, and it should be borne in mind that the presence of this header can vary between browsers and versions (e.g. no older browser support).
Note that this would not help in your example as a MITM could, in most cases, simply just spoof the Origin.

Shouldn't they only respond when Cross-origin resource sharing (CORS) is enabled on them?

All the problems with cross origin requests have been solved in some way such as browsers all following the Same Origin Policy and websites using tokens to prevent CSRF. This is the web - insecure by default. If a website is developed with security in mind, these problems can be overcome.