Is ECDSA breakable by quantum computers?

Short answer: Yes.

  Elliptic curve cryptography is vulnerable to a modified Shor's algorithm for solving the discrete logarithm problem on elliptic curves.


You are essentially asking to allow access from outside to some internal system, i.e. a system which is in the same internal network with other machines where access to these machines should not be allowed from the outside.

If an attacker manages to break out of your application due to some security issue it means that the attacker can now access and attack all the other machines in the local network. Because of this it is quite understandable that IT team does not want to allow this kind of access.

  But would this not be mitigated by only allowing access on a single port, to a single machine in the network?

Access to this specific port is enough to break out of your application if the application is insecure. It does not protect against attacking the rest of the internal network from the compromised machine.

  ... but I would argue that it's designed to be public facing anyway, so at this point their justification falls down.

Public facing services should be put into a separate network zone (DMZ) where they are reachable from the outside but have no access to the internal network. This way the impact of a compromise is reduced to this separate zone but cannot affect the internal network.


Which browsers don't support Forward Secrecy and ECDHE

Most browsers (all the major ones) allow you to change the set of cipher suites in use. Some may require obscure ways to do this (I'm looking at you chrome) and others may depend upon the cryptography packages provided by the operating systems.

Chrome, Opera and Firefox support FS pretty well out of the box. IE and Safari will require some tweaking. Check out SSL Lab's list of user agent capabilities.

Forward secrecy involves the use of ephemeral keys which are not transmitted across the network. This assumes that neither side has been compromised. Qualys has a good overview of FS.


Edited answer as my initial understanding was both the password and domain were easily guessable.

An RDP port exposed to the public internet is unnecessarily risky, and you should take whatever steps you can to put it behind the VPN you suggested. While the password isn't easily guessable, taking it off the public internet removes an attacker's opportunity to attempt to guess the password at all.

RDP doesn't have a great history with security vulnerabilities - if you're running an old version it is likely to be exploited, and there is no guarantee the current version isn't vulnerable to some currently unknown exploit.

Exposing an adequately-secured RDP port on the open internet isn't a guaranteed entry point for attackers into your network, but it is a high and unnecessary risk that. Off the top of my head I can't imagine a use case where a doesn't have VPN access but does have RDP access to a server on that network - unless you have a very good reason for it the RDP port should be behind the VPN.


Unknown automatically generated email in sent folder

The message line that was automatically sent says "This message was automatically generated by Gmail". It means that you marked a previous received message as spam, so it automatically sends a notification to Google in order to block further reception or messages from the same sender. Nothing to really worry about.


Is it reasonable to keep control panel in separate subdomain or domain?

Would implementation of separation of frontend and backend increase website security in any noticeable or reasonable way?

Yes. Splitting the interfaces over two hostnames—or indeed two port numbers or protocols (HTTP/HTTPS)—would give you two different JavaScript origins. This prevents any cross-site-scripting (XSS) attacks that are accessible on one site from automatically infecting into the other site.

For example if you had an HTML-injection vulnerability in your public site, it could include some JavaScript that automatically loaded the admin interface and simulated the user pressing the big red destroy-the-site button (or whatever other sensitive feature is there). If an administrator browsed the compromised public page whilst they had an active session on the admin site, the site goes boom.

With two different origins, the injected JavaScript on one origin cannot interact with the controls on the other, so the damage is limited to whatever can be done on the public site.

(As a side issue, having separate login sessions for each interface can also mitigate XSS and cross-site request forgery vulnerabilities, in that the administrator is less likely to be logged in to the admin site at the time they browse the public site. It's possible to have separate or combined login sessions either with or without different hostnames, but usually separate hostnames would give you separate logins unless you specifically worked around that.)

Separating internal-audience interfaces by hostname is generally a helpful mitigation for this reason, but of course cross-site scripting is only one minor facet of webapp security and you shouldn't imagine it gives you any protection against the other application and infrastructure security issues like DDoS.

(And yes, the comment about access control security being irrelevant because of DDoS is completely nonsensical. They are almost entirely unrelated attacks, done by different people for different reasons. How much you want to concentrate on countering each should be driven by the threat model for your application, but both kinds of attacks are commonplace and the existence of one is not an excuse to ignore the other. Typically a DoS alone is considered a lesser attack than intrusion or data loss, but again that would depend on the threat model—does an attacker have anything to gain by making your service unavailable? is it critical enough to cause serious inconvenience when it is down?)


The difference between authentication protocols and authentications rules

The two notions may indeed be confusing since by definition a protocol is itself a set of rules. But in case of ISO/IEC 25023 the meanings are  different and I think the best definition could be a tangible example:

Suppose you use any authentication protocol that uses ID/Password method as you said: the authentication rules could be, for example, a set f these ones:

The password must be hashed
The inputs must be sanitized to prevent SQL injections
The ID must be number
The ID must not exceed 25 digits
...

An authentication rule is a set of measures taken to deploy the authentication protocol in practice.


The attack is described in Analysis of the SSL 3.0 protocol from David Wagner and Bruce Schneier in section "4.3 Dropping the change cipher spec message". In short:

The attack works by stripping the ChangeCipherSpec message (but not the Finished message). This works since the (existence and content of the) ChangeCipherSpec message is not protected by the MAC in the Finished message.
The attack works only when a cipher is used which provides no or only very weak encryption, i.e. the encryption of the Finished message must be none or weak enough to break it in real time.
The language in TLS 1.0 makes it more clear that there should be no Finished message without preceding ChangeCipherSpec.

For more details see the paper.


openssl vs gpg for file based encryption? Pros vs cons for security?

If you're just encrypting it for yourself, then I don't think there's any advantage to one or the other.  In either case you have a secret key you need to protect.

If you're encrypting to send to someone else then I believe PGP is preferable because you never have to share the secret key needed to decrypt the data with the other person, though the other person's public key does need to be shared.  Please understand that PGP is hybrid encryption, using both RSA and symmetric encryption (I would suggest you use AES).


As someone who has overseen a number of shared CISOs and sold organisations on the need for someone in this role, I can tell you that the problem is that each organisation has different needs and different expectations of a CISO. Some expect operational support, some require a dedicated risk expert, some just want a Board-level representative of the security function who acts as a translator.

The core goal for the organisation is to know the risks, manage and monitor the risks, and communicate the risks to the organisations and any stakeholders. The CISO needs to think about the risks that the organisation cannot.

As an addition, the CISO should be able to lead the security function, the risk function, and/or the regulatory function of the business. But the expectations here are up to the organisation.

Deloitte has it's "Four Faces of the CISO" which is a pretty good guide for what a CISO should be.

  CISOs continue to serve the vital functions of managing security
  technologies (technologist) and protecting enterprise assets
  (guardian). At the same time, they are increasingly expected to focus
  more on setting security strategy (strategist) and advising business
  leaders on security’s importance (advisor).

So, there is no set list of "things to do" for a CISO. There is a long list of things that need to be done, but you do not need a CISO to do them. For that, grab a framework (ISO 27001, NIST CSF, Cyber Essentials, etc.) and start the work. Your list in your question is a small set of things to tackle, but a good list.


Is this website vulnerable to an SQL injection?

I'm afraid there isn't much information to go on here in terms of answering your question. SQL injection vulnerabilities make themselves visible through very specific error messages, showing the server's inability to handle the SQL query being passed to them. As a corollary, in order to find that error message, you'll need to make sure you're querying on something that will transform into SQL and inject itself into the server.

It sounds like SQL injection attacks might be something you're not too familiar with, so I'd suggest doing a little more background research. I find this Computerphile video to be especially educational on the topic. And to try out SQL injection on an application that is vulnerable, I'd play around with Juice Shop (from OWASP).

Hope this helps! Feel free to ask any more questions you have on this.


OpenVAS: This CPE does not appear in the CPE dictionary but is referenced by one or more CVE

I encountered this same issue using OpenVAS on Kali Linux from behind a firewall that doesn't allow the rsync protocol outbound. Most of the OpenVAS updates use HTTPS, but one of its databases can only be updated via the rsync protocol.

Look at any firewall logs from between your OpenVAS system and the internet to confirm there are rsync connections being dropped, and if so open it temporarily while running OpenVAS updates.


Custom programming language, and translator that translate it to Java to make more difficult to get source

I'd say that the flaw in your reasoning is that you assume that any wannabe reverse-engineer would be interested in your source code. In fact, for reverse-engineering, attackers are interested in a "source code" form which allows for whatever goal the attacker is after, usually understanding a small piece of algorithm. The format for Java bytecode is sufficiently regular and simple that it can be managed directly for that kind of job.

So an attacker could simply run a disassembler (like this one) and possibly a corresponding assembler (like that one) to test his modifications or insert extra debugging calls. He can do that on the compiled .class files, regardless of whatever programming language you used on your side.

This is not new. People have been reverse-engineering C or C++ applications for decades, by looking at the assembly.


Why isn't XXE part of Injection in the OWASP Top 10?

Even in MITRE CAPEC, Injection is a distinctly-separate top-level category from Subversion of Acess Control. XXE is a type of Privilege Abuse that falls under Subversion of Access Control, not Injection.

i.e.,

  Inject Unexpected Items -> Command Injection -> XML Injection

Totally different from

  Subvert Access Control -> Privilege Abuse -> XML External Entities


NMAP host discovery reporting discrepant results between NAT and Bridged mode

VirtualBox sets the NAT up with its own IP address range and set of rules like the NAT in your router. So to get to the internet you are actually going through two NAT interfaces.

VirtualBox's NAT network treats all 256 IP addresses as online hosts because of
the internal VirtualBox NAT configuration. Bridged mode bridges you directly with
your NIC using your host's configuration which is why those results are more accurate.


I want to implement a new type of security feature over several platforms

Keystroke Dynamics has been suggested in various forms since World War 2. More recently, there was a paper published on continuous keystroke dynamic authentication (end of 2011) so I'll link to it when I find it.

Your second part is unethical/illegal and also pointless - it is trivial to change MAC addresses so it would not be a good way to build a black list.


Legality and ethics of cryptanalysis on password hashes

"Legality" is about laws which change quite a lot depending on the country. Start your search by this site which is a survey on laws about cryptography in various countries. Though the survey is about laws which restrict (or not) the usage for cryptographic tools, it may contain pointers to laws about password cracking tools.

In countries which use Common Law or a variant thereof (e.g. the USA), the authoritative source for legality of password cracking will include cases which have been brought to a judge. This Web page quotes a case of prosecution of someone in 1995 for having run a password cracking tool. Since the perpetrator (technically an invalid qualification, since the records were expunged) was a high profile figure in Internet-related circles, there will probably be extensive documentation on the case (e.g. this page) that will yield a lot of material for your dissertation.

As for ethics, I would say that passwords are private data, which the users feel as such. Knowing a password not only gives you access to the system which is protected by that password, but also gives you some insight into the private parts of the life and brain of the password owner. As a simple example, many people will use as password the name of their current or potential future girlfriend/boyfriend (a terrible way of choosing password, but users do that).

I would say that running password cracking tools is ethically valid as long as:

users have duly been made aware, when they chose their password, that such tools may be run;
passwords which are thus found are not disclosed to third parties, except under anonymization (no way to link the password back to the user).

There are several moral systems out there; although I believe mine is better than all others (I am not a moral relativist), I acknowledge the fact that some people will not agree with me on this subject.


What are the security risks associated with PDF files?

One PDF-specific risk is that Adobe and third-party reader extensions are supported: your PDF viewer may have extra modules loaded, or may require them to open certain documents. Examples include:

Adobe LiveCycle Rights Management ES4
Time limited PDFs for which there are commercial products

Both of these endeavour to constrain digital document use. At best, such features increase the attack surface, and at worst may deny you access to some of your files, report on your activity or otherwise take liberties with your privacy, documents, computer or network. (Sound familiar? Seems analogous to a browser and web page that needs Flash  or a similar proprietary plugin.)
See also this question which covers PDF phone-home capability. Javascript, embedded multi-media (including, but not limited to Flash) and Xobjects (external streams) are at least some of the ways to achieve that.
Some less-obvious risks associated with, but not entirely specific to PDFs:

PDFs can contain attachments, though not all readers support this, and those that do don't always visually indicate their presence. These can be any type of file, including another PDF. An encrypted PDF (commonly RC4 or AES) is identifiable as a PDF (only the data streams are encrypted, rather than the file as a whole), the presence of attachments is not evident in this case. Behaviour is restricted on some platforms at least, see Adobe's KB 331371 and KB 328671. (I consider this is a potential risk because it comes as a surprise to many people, and it may be used for stealth transfer. The "Peachy" worm is a proof-of-concept example)

Misplaced faith in native "security features" such as no-copy, no-print, no-edit. These are effectively discretionary controls, at the discretion of the viewer software itself.

The structure/layout of the PDF format is quite loose, and PDF lends itself to use and abuse as a chameleon or polyglot format (PDF), see Corkami's examples here:
http://code.google.com/p/corkami/wiki/mix?show=content . This show files which are simultaneously PDF, native binary executable, .jar and .html by using similar "slack" in those formats.

Metadata may leak information about the document origins or history. Sloppy redaction is also problem.

Support for rich content (multimedia via Flash, embedded fonts) and browser integration facilitate attacks on client-side software components beyond the reader/viewer itself

See the Acrobat Application Security Guide for further details.
There are two types of PDF passwords, in Adobe terminology the user and owner passwords. The user password is used for encryption, the owner password is used for discretionary access control. These may be augmented by proprietary controls via extensions.
Password protection can be secure (using RC4-128, AES-128, AES-256 with good key derivation), but RC4-40 is still supported, and Adobe fumbled the ball with the initial AES-256 implementation in Acrobat 9/PDF 1.7 by omitting iterations in the KDF:

While this allows for 256-bit AES password protected documents to open faster in Acrobat 9, it can also allow external brute-force cracking tools to attempt to guess document passwords more rapidly because fewer processor cycles are required to test each password guess.

Applies to Acrobat 9 PDF 1.7 ExtensionLevel 3 (2008), fixed in Acrobat X PDF 1.7 ExtensionLevel 8 (which became ISO PDF 2.0). You can read some background to that issue in Sin 21 of 24 Deadly Sins of Software Security. PDF version specific details can be found here:
https://www.pdflib.com/pdf-knowledge-base/pdf-password-security/encryption/
In summary:

PDFs are feature rich, and the implementation potentially complex, both of which contribute to an increased attack surface
support is multi-platform and since it continues to be the de-facto document format, approaching ubiquitous, making it a popular target. ISO standardisation of PDF 2.0 furthers this.
PDFs provide a vector for attack payloads (Javascript, multimedia formats, fonts, arbitrary attachments) both by design, and by accident

As with Flash, I've long had concerns about Adobe Reader's approach to browser integration which can do nothing positive for the attack surface of a browser. With native browser support for PDFs this problem is shifting away from being an Acrobat issue at least.
The result of the above (combined with the near legendary bloat of the canonical PDF reader) can been seen in the CVE statistics for Acrobat/Reader (though note there are several other Acrobat/Reader variations with separate counts, and those stats stop around 2018).


Can a deleted PGP secret key be recovered from private-keys-v1.d directory?

The question is based on the wrong assumption that for each PGP pair there is one and only one entry in the private-keys-v1.d directory. The private-keys-v1.d directory comprises the key store of the gpg-agent so apart from the private keys used by gpg there may exist other keys used by SSH or X.509 or secret subkeys.

Deleted keys are not going to be present in this directory. On the other hand if you have at hand the private-keys-v1.d directory it is possible to restore the keys as explained here.


Is there any SQL injection for this PHP login example?

You've come to the right place. Welcome to IT security!

  is there any sql injection for this code?

Yes

  if there is what is that Entry?

username: [any username from your website]" /*
password: sux0r")*/ OR ("1"="1

It will run this query:

SELECT * FROM `config`
WHERE `config_admin_username`="[any username from your website]" /*
      AND `config_admin_password`=MD5("sux0r")*/ OR ("1"="1") LIMIT 1'

If we remove the commented-out parts that SQL engine won't parse, this results in:

SELECT * FROM `config`
WHERE `config_admin_username`="[any username from your website]" OR ("1"="1") LIMIT 1'

SQL query will be parsed up till the commented out part (I used the /* and */ start-comment/end-comment pair in my example and assuming you're using MySQL, but that can be different depending on RDBMS used), effectively disabling your password check altogether. Even if in-SQL commenting is not supported, or disabled, the options to exploit your login are really limitless. I won't even go into your choice of MD5 as a password hashing algorithm, as you have a lot of other things to consider first. It clearly isn't the recommended hash algorithm for password hashing though.

You've done good to have come to this website and that you're asking yourself questions regarding your code safety. Congratulations, you're already a better PHP programmer than most that never got so far are! Now, it's up to you what you'll learn from already existing questions and answers here. Some tags to consider are php, authentication, web-application, hash,...


How can I check a .srt and .txt file for malware?

Both .srt and .txt subtitles and like other well known formats are pure test files - they contain text with time indexes and that's it.

It is highly unlikely that a random malware can spread by itself even if inserted in such files.

However, the only thing you should worry about are special vulnerabilities which could in theory specifically crafted so that a specific player's subtitle interpreter ends up doing something unwanted. There are over 25 subtitle formats in use, each with unique features and capabilities, which could be exploited against a specific player.

Here's an example: The StripTags function in the USF decoder and the Text decoder in VideoLAN VLC Media Player 1.1 before 1.1.6-rc allows remote attackers to execute arbitrary code via a subtitle with an opening "<" without a closing ">" in an MKV file, which triggers heap memory corruption.

Here's a take-over example video.

So, to make sure everything is fine, the 1st step is to make sure that your anti-virus solution does scan such files and does not ignore them (considering them text only and not scanning them).

Then, the next step is to patch the media players you use.


Reducing risk for malware exposure from USB storage devices

BitLocker would possibly reduce the risk for old-school viruses that embed themselves directly in executable files. However, there is a whole class of USB vulnerabilities that exist at the hardware level, that lives below any partition or file system scheme. While it would protect against some viruses doing their thing, I'd consider investing in a hardened USB drive that offers firmware protection and encryption. Normal consumer USB drives simply cannot be trusted to resist infection when you try to protect them at the OS level. (NOTE: This link is only meant to provide an example; actual research on available options is strongly recommended).


How to stop brute force attack that is DDoSing our server?

What you have is not so much a brute force problem but a load problem. Specifically, you have to think about it as a DDoS scenario. Multiple IPs hitting your server and consuming resources.

Account-level protections are not going to do anything, you need to handle the attack at the traffic level.

DDoS mitigation services are exactly what you need, but depending on the attack complexity, they might be too expensive. You could try working with your hosting company or ISP to see what they might be able to do.


How to verify if router firmware is legitimate

There is no generic way to check if a downloaded firmware is the original one. A vendor might provide tools for this or not. But a properly designed update process would already include that the firmware is signed and that the signature is checked by the router. This does not mean that the update process for your particular system was designed as such. For specific information please refer to the vendor of the product you use.


Should I ignore the BEAST SSL exploit and continue to prefer AES?

1) This is not exploited through XSS, but through a client visiting a malicious site. The targeted website does not need to exhibit any flaws at all. Details: http://vnhacker.blogspot.com/2011/09/beast.html

2) RC4 in WEP was vulnerable because of an implementation flaw. AES in TLS 1.0 / CBC mode... exactly the same kind of problem. They're still strong algorithms, they just had an error in how they were used.

Browsers are adapting by sending one-byte packets at the beginning of connections. This makes the remainder filled with random padding and thus negates the ability to use chosen plaintext based upon the CBC initialization.

Should you change ciphers? Well, RC4 defeats the attack, does not present a known new attack surface, and Google seems to be doing quite well with it. For those reasons, I personally would change it.


Current Session can be checked with any request, so implement user privileges and check if current user has the required privillage to do the operation. Also make sure prpoper csrf protection is given to that form


Bad transactions in an e-commerce system?

Almost all of them do rely on having a stolen credit card.  The trick is in trying to catch that, particularly if the card hasn't been reported as missing yet.  This is especially difficult if the attacker has the physical card, or the security code, and knows the address of the victim.

There are several "red flags" that can indicate potential fraud of this nature:

Unusual amount of transactions
A small "test " transaction followed by several unusual large transactions
Shipping address other than what the issuing bank has online (particularly to PO boxes)
mismatch of some data
and many more I hope never to have to learn about.

Software like this is designed to help to catch transactions for people who have access to a lot of the potential victim's data.  Given how freely available PID is these days, tools like this are, unfortunately, necessary.

There are other solutions out there, including one from TransUnion, Idology, and many others.

There is more information in a video on the Signifyd website.


TRUSTWAVE pci network vulnerability scan FAIL

I can see that most of the findings are related to port 3389 which is for remote desktop. You have some issues related to SSL certificate you use for remote desktop. I will try to mentioned and give some guidance for solving some of them.

TLSv1.0 is supported the port support what seems to an obsolete
version of TLS, you need to reconfigure the service to not support
this protocol version, I haven't done this myself before but as described here, it seems that there is a patch for this.
SS/TLS weak encryption algorithm, you remote desktop service support
weak algorithms, for this one you need to set the encryption level
to high from terminal services snap-in type tscc.msc in run please
refer to this link if needed and this link as well.

For the rest, you can google the error messages and see which configuration you need to change in the terminal service configuration. I hope this helps a little. I would help with the rest as well if you struggle.


These aren't books, but you may find the info useful:

BSIMM - the Building Security In Maturity Model
OpenSAMM - Open-Source Security Software Assurance Maturity Model

Security Maturity Models tend to provide a lot of info on building security in from the start, defining Secure Development Lifecycles and managing governance and change in order to raise security baselines.

They don't go into any depth on languages or api's though, more around what you would want to look for or measure or control, so this answer may not work for you. Have a read of them both anyway and see.


There is no short cut. Brute forcing it is the way to go.


What is the proper way to view the sourcecode of a website?

Yes, modern browsers such as Firefox, Chrome do make a second requests if you view source. And that does mean the source may be different from the one that is being displayed.

If you want the original source, you should use some add-on such as web developer toolbar (https://addons.mozilla.org/en-US/firefox/addon/60). Then use View Generated Source.


There is whole world of vulnerabilities out there which don't need buffer overflows or bad crypto. Just have a look at  web applications where you have all these web based insecurities like Cross Site Scripting (XSS) or Cross Site Request Forgery (CSRF). Then take a look at code injections like SQL injection or Remote File Inclusion. If this is not enough have a look at the latest Ransomware which makes use the Windows Scripting Host etc. No buffer overflows or bad crypto is needed for all this.

  Is this profession/art coming to an end?

Don't worry. The increasing complexity of current systems combined with security as an afterthought opens enough new attack vectors, even though some older ones might vanish. Just have a look at the whole IoT mess for example.


nmap to scan all resolved ip addresses for a given domain name?

Nmap has a script to do this, resolveall. The interface isn't as nice as it could be: you have to provide the hostname via the resolveall.hosts script argument. Here's how to do that and also add any resolved addresses to the scan queue:

nmap --script resolveall --script-args newtargets,resolveall.hosts=example.com

EDIT: As mentioned in the comments, Nmap 7.40 and later does not require the resolveall.hosts script argument; you can provide targets directly on the command line or with -iL as you usually would. The newtargets argument is required to add the resolved addresses to the scan queue instead of just listing them in the script's output. Future releases of Nmap (newer than 7.60) will have non-NSE capability to do this, but the options and syntax have not been decided yet.

EDIT 2: Nmap 7.70 (released today) has this functionality built-in with the --resolve-all option. No need to use the resolveall NSE script, which will be removed in a future release, and no need to use the newtargets script argument.


Generating private key from hex string with openssl

I'm afraid what you're asking doesn't make a lot of sense.

If indeed you already have the set of numbers that compose your private key, then all you need to do is express that as a string. And if you can already do that, then what do you need openssl for? And if you can't do that, then how are you going to communicate them to openssl? Typically if you actually have the data at all, then you also have the means to output it into a standard file format.

The standard key format used in x509 is simply ASN.1 data formatted using DER (binary) or PEM (base64) formatting rules. Here's a fun activity to see what it looks like:

$ openssl genrsa > key.pem

Now we have a 512-bit RSA keypair. Not particularly useful, but small.

$ openssl rsa -text < key.pem
Private-Key: (512 bit)
modulus:
    00:cc:95:9a:a2:ac:03:6b:77:11:52:be:06:86:8e:
    ....
publicExponent: 65537 (0x10001)
privateExponent:
    00:91:d1:b0:3e:72:4c:9d:b4:68:6c:89:75:2d:43:
    ....

So that's your private key. The first two fields; the modulus and publicExponent are also your public key.

How is this stored? We can ASN.1 decode it without additional processing:

$ openssl asn1parse < key.pem
    0:d=0  hl=4 l= 316 cons: SEQUENCE
    4:d=1  hl=2 l=   1 prim: INTEGER           :00
    7:d=1  hl=2 l=  65 prim: INTEGER           :CC959AA2AC036B77...
   74:d=1  hl=2 l=   3 prim: INTEGER           :010001
   79:d=1  hl=2 l=  65 prim: INTEGER           :91D1B03E724C9DB4...
  146:d=1  hl=2 l=  33 prim: INTEGER           :E831F72E74263DDC...
   ...

As you can see, the file simply contains the expected data fields dropped in there one after the other, with no fluff. As long as you have the right ASN.1 identifiers for each field, you're pretty much done.

Of course, if you don't want to bother with the binary encoding rules, you can read the ASN.1 fields in as text using the "conf file" format described in the documentation for ASN1_generate_nconf. It looks more like this:

asn1=SEQUENCE:private_key
[private_key]
version=INTEGER:0
n=INTEGER:0xCC959AA2AC036B77...
e=INTEGER:0x010001
d=INTEGER:0x91D1B03E724C9DB4...

You can load this format in to the asn1parse command using the -genconf <file> option, but I'm not sure the command line program allows you to then output a PEM or DER file from the contents. Though, realistically, a C program that uses the openssl API to do just that would only be about 20 lines long, so it's something you could easily do if necessary.

Still, this all sounds pretty contrived; why you would possibly need to do this is beyond me. But I would imagine that if you were well-versed in this technology enough to know that you did need to do it, then the writing the appropriate utility to do so would be trivial.


Yup, absolutely. PGP was not designed for anonymity -- quite the opposite in fact, it's designed so you can prove that you are who you say you are, and so people you've never met in person can easily look up your key and send you secure email. The idea of "anonymous PGP keys" doesn't really make sense.

Name and email address are required fields when creating a new key, and they get embedded into the key (along with a photo if you want). There is of course nothing stopping you from putting garbage into these fields if you are trying to hide your identity, but the better PGP clients I've used automatically use the To: and From: fields in the email to decide which keys in your PGP contacts list encrypt for / verify against. Putting in a garbage email address might actually make your key very difficult to use.

For example you can easily find my PGP key by searching my name or email address on the public pgp key servers, this is how the system is designed to work:

pub  4096R/62F715FD 2015-02-24 Mike Ounsworth <ounsworth@gmail.com>

You are not required to publish your key to a key server (but the more you use it, the higher the chance that one of your friends' clients will automatically publish it for you).


Identify users accessing hidden link in a website

All websites should be receiving regular attacks,  if you are not begin attacked,  please check your internet connection.

A link is in no way shape or form "hidden" if a robot can find them.  A malicious bot will use a robots.txt file to enumerate resources on your system ignoring the deny directive.   Using a CAPTCHA will prevent automated attacks.  Also consider password protecting "hidden" links.


Bitlocker works at the volume level, replacing the file system metadata with its own and moving the FS metadata into the encrypted volume (for this reason, BitLocker needs to understand the file system format, so it knows where there is free space for the metadata, and how to mark that space as no longer free). It is Full Volume Encryption, not Full Disk Encryption, and doesn't touch anything outside of a logical volume (which might be a physical partition, or a RAID volume, or possibly something else).

I don't know if BitLocker has any special logic for dealing with bad sectors.


Am I safe from XSS in React as long as I don't use dangerouslySetInnerHTML?

I wouldn't say "Safe". ReactJS is reasonably safe by design as long as you use it the way it’s meant to be used. Among other things, do not use dangerouslySetInnerHTML.

However, there are other ways a dedicated attacker can find a way to bypass the XSS roadblocks on your app. Some of them are listed in this DailyJS article:

  Creating React components from user-supplied objects;
  Rendering links with user-supplied href attributes, or other HTML tags with injectable attributes (link tag, HMTL5 imports);
  Explicitly setting the dangerouslySetInnerHTML prop of an element;
  Passing user-supplied strings to eval().

The safest stance to take would be to Trust but Verify. By default, you must not trust ANY user input. As much as React will take care of most of the security for you client side, make sure you also implement security checks server side as well on ALL user inputs/functions.


Which approach is technically more effective to hinder user tracking - fingerprint generalization or randomization?

You are comparing apples with oranges.

Tor makes standard only those parameters that can be the same without any disadvantages to the user. For instance, window size or agent string. But some parameters like result of drawing something on canvas cannot be done standard. If you draw things in the same way everywhere, the web page can look unreadable.

What Brave and many FireFox and Chrome extensions do, is adding some noise to such  data like drawing on canvas.  As long as changes remain small and not perceivable, users don't complain about the negative effects of such noise. But this is also a limitation of such protection method. Because making sure the noise is not perceivable means that some statistical parameters must remain in a limited range. This means that despite some information provided by canvas is lost, it remains still not null and can still be used to compute a fingerprint.

What of these methods is more effective depends on particular fingerprinting algorithm. If algorithm uses canvas fingerprint blindly, believing it gets say 15 bits, then actually we should subtract these bits because they will be different each time. Thus Brave approach would be more effective.

But if some site uses another fingerprinting, calculates some statistical values (some average values, deviations, etc.), then in general it gets less bits of information, let say 5 bits instead of 15. But it remains resistant to small noise added. Thus this fingerprint will be the same for Brave and for Tor, where as Tor has some other parameters standardized. In such case Tor will be more effective.

There is no simple answer.

Update

We should consider also the other side: the web site that computes your fingerprint. The meaning of effective depends a lot depends on many factors:

... on the purpose of fingerprinting: may be the web site doesn't have any interest in particular persons, but just wants to have to measure some metrics about its users; as long as they get statistics with acceptable precision, they will not invest much budget into development of very complex fingerprinting. Other web sites for their needs will develop more complex algorithms so that both Tor and Brave are fingerprintable
... on the skills of developers designing and implementing fingerprinting for particular web site: in one case Tor and Brave can both be effective, in other case the countermeasures of the both can be insufficient
... on the budget available: if a web site can afford sufficient budget for research, for design of complex algorithm, for its implementation in a good quality, for its maintenance, then both Tor and Brave can be too weak to prevent precise fingerprinting

And this is of course an arms race: after one side found a countermeasure, the other will work to make it ineffective.

In general, I think fingerprinting is in the most cases unavoidable as long as the code you download from web sites is allowed to communicate with these web sites.

That's why I find it very naive, that there is a legal requirements in the last years to inform users about cookies used. Fingerprinting requires more resources to keep data and to correlate across different web sites, but it does its job. One can delete cookies in the browser or user ad blocker. But preventing unique fingerprints is much more complex.


No, not that I'd know of. You could maybe remove the dmsetup binary from the system and only keep it in the initial ram disk, which would be enough to set up the encrypted volumes when the machine booted, and then chroot the initial ramdisk out of reach in the booted system, but this would only be a stopgap measure. You might be able to improve on it with apparmor profiles a bit, but not make it watertight (especially not against a simple download of the binary from the network).

That said, Luks is designed to keep data confidential only when it is at rest. If you're trying to avoid having the luks key stolen while the container is in use, that will most likely turn out to be hopeless.

To expand on that a bit: Even if the dmsetup binary could be coaxed into not outputting the key, root would still have access to /proc/, which would allow him access to system memory, to the encryption and decryption etc. The only way to keep the key fairly safe would be to prevent the kernel itself having access to the key, and that's obviously not possible with just software.


how does a site know it is me even after changing ip address and clearing cookie?

It probably blocks an entire IP range because of abuse. So if you get another IP address, it probably is still in the same range, like 12.34.56.xx. In that case it doesn't matter if xx=3 or xx=123. If you use another computer on the same local network (like smartphone with wifi or VM with different OS), and still have this problem, that means they block the range.

Your use of TOR may be seen as abuse. I've had this myself. I had a TOR node installed on a home server. The result was that I was blocked on one discussion forum. I mailed them about it because the site was totally blank at home, while it worked elsewhere. They said my IP was blacklisted because of TOR. And this was a normal TOR node, not an exit node! I told them this and they (an IT site) acknowledged it as being a wrong block, but couldn't remove my IP from the blacklist.

Another option is that they identify the computer using CSS and Javascript. There are several options like checking screen size and which fonts you have installed. This is probably enough to uniquely identify your computer.


Best practices to invalidate JWT while changing passwords and logout in node.js?

There's no solution unless you are hitting the DB. You could reduce the number of lookups though to one instead of two.

Upon password change or logout, you write a 128 bit number generated by a CSPRNG to that user's row in your user table.

This CSPRNG forms part of the JWT. On every access you would need to check that the number in the JWT matches the value stored in the DB. There's also no advantage to the MAC being calculated over this value, we are just keeping it in the JWT so everything is in one place.

This sorta defeats the purpose of using JWT in the first place - you might as well simply use a session token that is checked server-side. The advantage though is that you don't need to maintain individual sessions server-side as once a JWT expires it has expired because you won't accept any with expiry dates in the past.

Another disadvantage is that if there are two sessions against the same user, logging out one would logout the other. Also, the logic is more complicated than a server-side managed system, and extra complexity tends to reduce security.


The likely scenario is that the sender's account got compromised, not necessarily their computer. Accounts are easier to hack because attackers just need to guess a password.

Responding has a high chance of alerting the sender, so it is worth a shot. Sometimes an attacker has active control of the account and will try to delete incoming emails, but I haven't seen that often. Even if that is the case, it is still worth a shot.

Blocking the domain of the link in your spam blocker will not be effective. The email comes from a completely different domain than the link destination. On the other hand, if you want to block that domain in your DNS or web filtering software, that might help a little, but those domains tend to exist for short periods of time.


Setting up a security lab, looking for a little guidance

You first want to set up a host OS (Windows or Kali, whichever you prefer to use when you're not hacking.)  Inside that host OS, install a virtual machine platform (VMware, VirtualBox, whatever you choose.)  Inside the virtual machine control panel, create a first VM and install Kali, (presuming you want to use Kali for your pentest environment.)  I would configure the virtual network adapter of this first VM to permit it to connect to the internet so you can install updates, new tools, or whatever.  You can always disable this virtual network adapter later if you're going to try something risky.

Now, go back to the Virtual Box control panel, create a second VM to be your victim, and install a vulnerable guest OS such as Windows, or whatever other OS you want to attack.  Add a virtual network adapter to each VM that connects your VMs to each other, configuring this little virtual network so both the pentest and victim VMs are on the same virtual network.  Once it's all working to your liking, save a backup of your victim machine's virtual hard disk (VHD) image, and save your virtual machine configuration.  You now have an environment where you can instantly bring up a clean battleground, allowing you to test a fresh system from a known starting point.

You can install anything you like in your vulnerable system, hack on it all you want, infect it with malware, whatever.  Then when you want to try something else, restore a copy of the clean VHD image, and you're back to square one.

If you do plan to install malware on the victim, I'd recommend disabling any virtual adapter on the victim VM that allows it to connect to the host system or to the internet before you infect it.  You don't want this VM to infect the other computers in your home!  This is the main reason for running the pentest environment in its own VM, instead of directly on your host OS.  It could help contain the damage if your malware finds your Kali VM on the virtual network and tries to spread to it.

Another nice thing about the VM approach is that if you have an expiring licensed demo copy of something you want to attack, you can install it on a fresh VHD, attack it, and when it expires you just delete the old VHD, reinstall on a new VHD, and resume your attack.

As you learn how to break in, be sure to study how to configure the victim machine to prevent those kinds of attacks.  Whenever you like, perhaps when you discover something interesting, you can save a copy of the VHD so you can restore the machine to that point some time in the future.

Consider storing the victim machine's VHDs on removable media, such as flash drives or an external hard disk, or on a large network storage appliance.  Each VHD is a huge file, and you'll probably acquire a lot of them.  It helps to have a way to organize them that doesn't eat your system's main hard disks.  You may find a forensic tool like Autopsy helps keep your experiments organized.

Once you get practiced and comfortable with this setup, you will soon be creating different virtual machines with different operating systems to see how they can be attacked.  You may eventually add a third VM running a firewall, router, or other network appliance to see how to attack from outside a network, or how an NDIS might alert you to attacks.

Eventually when you're ready to tackle an external client's system, consider connecting a USB network adapter in your virtual Kali instance to help isolate your laptop from the client.  If you're going to work in a client environment that already has malware, make a backup of your Kali VHD, and run your VM using a clean copy.  This can help prevent it from spreading, and it's especially important to not spread an infection from one client to the next.


What are reasons why one shouldn't run Tor at a network level?

This is a question of threat modelling. Which adversary are you most concerned about? Tor has the advantage of obscuring the origins of the traffic, which makes it difficult for your ISP, as well as the destinations of your traffic to track you. The adversary you should be worried about is the exit nodes. Since anyone can run an exit node, it's lucrative to sniff unencrypted traffic for information, such as passwords, credentials or other personal information. Furthermore, a really clever exit node could use your credentials transparently—after all the connection appears to be coming from the exit node—for example to spam (in the case of forums, or other communication) or spread malware (in the case of say an uncencrypted FTP connection.)

As long as you can guarantee that all network traffic you are generating has strong encryption and trust (such as ssh fingerprints, which would not be known the first time you're connecting) it would be secure enough to route all your traffic through Tor.


Password capturing from dump file or browser after log out

Is it a vulnerability?  Yes.

Is it a severe vulnerability?  Probably not.  For an attacker to read a password out of memory, they need some way to read arbitrary parts of memory, either by running their own program on the computer (in which case security is already totally compromised) or by exploiting a use-after-free or similar bug to convince another program to do the reading for them.

As for a solution, it depends on where the password is coming from.  If it's Javascript, there's no surefire way to solve it: Chrome doesn't know there's anything special about the variable so it can't wipe it after use, and the Javascript can't count on successive writes to the variable ending up in the same piece of memory.


What security issues are there when reading cookie with .htaccess?

You want to tie to session IDs not user IDs.  User IDs don't change and can't expire.  They also can be forged if a user ID is known.  Since Session IDs are random, not re-used, and expire, it is far more difficult to make a valid session cookie without actually logging in.


Well, it's always possible for a device manufacturer to not follow the specification.  There was a question on Stackoverflow asking how to implement the standard ( https://stackoverflow.com/questions/6071474/how-to-implement-ans-x9-24-dukpt-using-java ) and they pointed to jPos: http://www.jpos.org/.  It appears to contain test data.


How do I secure "Data at Rest" only allowing Service API to access it from a mobile application

You could:

Encrypt/decrypt data in the client, then the server is just storing an opaque blob.
Have the client transmit a key that the server uses for encryption/decryption.

Any encryption algorithm provides what you want, what matters is key management.  Additionally, if your server is compromised, then encryption at rest only protects against adversaries not able to tamper with your operating environment.  If they can modify the server (which they usually are able to do, except for access to backups, etc.) then they can capture the data coming and going.  In that case, only client-side encryption will help.

And seriously, don't use md5 for passwords.  If you're using MD5 for password hashes, you've already put user's data at risk.  Leaked, unsalted, MD5s are basically as good as plaintext these days.  scrypt and bcrypt are considered the state of the art in password hash storage, but even salted SHA-2 will buy you a lot compared to MD5.


Bits do not make suicide after some time or degrade in quality. Thus it is not possible to construct a key which enforces the time limit by itself. Instead you would need some protected service or device which can be accessed with the shared key and will provide the real key or the decrypted data. The time restriction then must be enforced by this service.


Why bother validating the hostname for a Google Recaptcha response?

It may have something to do with people embedding your captchas on a site they set up, and using the solved captchas to spam your site.

For example, set up a site and give something for free (pirated movies/software, porn, etc) but ask for the captcha. Internally this is actually your captcha, and any solved captcha is passed down to a spambot targeting your site. This gives an attacker cost-efficient access to human captcha solving compared to the conventional captcha farms.

The hostname validation would prevent the captcha's JS from loading on an unauthorized site.

Update: I've recently implemented a demo of bypassing this by rendering the captcha on the original site in a headless browser and then using Websocket magic to stream it on my "bait" site (in this case a simple URL shortener that asks for the captcha before redirecting to the target site). This required considerable amounts of RAM (each Firefox instance was about 500MB) compared to the equivalent of rendering the captcha directly on the bait site, so this hostname verification feature is definitely a major pain for spammers.


Why are KDFs slow? Is using a KDF more secure than using the original secret?

The confusion here is that there are two distinct kinds of key generation function, and people often say "key derivation function" without being explicit which one they mean (or even understanding there are two):

Key-based key derivation functions
Password-based key derivation functions

A key-based derivation function like HKDF presupposes that the inputs may be biased or partially predictable, but that otherwise it has enough min-entropy to be reliably unguessable.  The shared secret produced by a Diffie-Hellman exchange is one of the textbook examples.

Password-based functions, on the other hand, assume that the inputs have low entropy, and thus they're designed to impose as high a cost as reasonable to a guessing attacks (without becoming unbearably costly to the honest parties).  Slowing down the computation by having a high number of iterations is the classic technique, but newer functions like scrypt and Argon2 go beyond this and aim to be memory-hard:

The canonical algorithm for computing them uses a large, tunable amount of memory;
Any algorithm for computing the function that uses less memory than the canonical one should pay a very high time penalty (adverse time-memory tradeoff).


AES-128 (or higher) is the recommended algorithm.

You should also choose a good Chaining Method with a random Initialization Vector. Padding variable length source data is helpful since AES is a block algorithm. AES/CBC/PKCS5Padding is a good option.

The encryption Key should be generated from a Cryptographically Secure (Pseudo-)Random Number Generator. (i.e. Java's SecureRandom)

Alternatively, the encryption key could be Derived from a reasonably strong Password using a suitable Key Derivation Function. (comparison here)

I'm assuming you need to encrypt data at rest. Key Management will have to be considered.

If you need to encrypt data in transit you'd also need MITM and Integrity verification, which is best accomplished with TLS. (HTTPS)


Web Services and WSDL Documentation Protocol

It is possible to keep the WSDL private,  or keep it cached on the client.  However,  this is just (in)security though obscurity.  WSDLs are useful for generating test cases against your web service,  and you should test your own service before any major release.


What are the advantages of sequential signing

If by "sequential signing" you mean "signing the encoded signature of someone (computed over a given document)", then this can be viewed as a kind of "countersignature", meant as a formal approval in a multi-layered hierarchy. E.g. some employee signs a purchase contract but it must also be approved by his chief.

CMS contains a format for that (section 11.4 in RFC 5652). However, CMS does that only on the "raw" encoded signature, without the original document or even any indication of which signature algorithm was actually used in the first place; this opens the road to a variety of tricks which make the actual semantics of CMS countersignatures a bit hard to nail down. For instance, it is possible, given an arbitrary bit string, to create an asymmetric key pair for which the bit string becomes a valid signature over an arbitrary document; so not only does the countersignature not prove that the countersigner saw the original document, but it is also possible that the countersigner saw another document and another public key for which the signature looked valid.


How do I know if my company or my ISP is using a TLS proxy?

How to know if your company does TLS intercept

As the post you linked to explains, the proxy will decrypt all the traffic, and then encrypt it again but signed with another certificate. Therefore the certificate you receive will be different from the one the website send. So one way to detect this is to compare the certificates you get when you visit a website from your company network with the one you get when you visit it from outside of that network (e.g. from home).

All browsers have functionality to view the thumbprint of a certificate. In Chrome, click the green lock in the URL bar, then click "Info", and finally "View certificate".

Some caveats, though:

Some websites may serve different certificates to different users for various reasons, so that they don't match for one site might not be enough to conclude there is a TLS proxy.
The proxy might not intercept traffic for all domains, so even if all the certificates you try match it is impossible to know that your traffic will never be intercepted.

So how do you get around those caveats? You would have to go through the trust store in your OS and your browser (if it uses it's own) to see if any certificates have been added there. For instructions on how to do this, see this question.

Finally, it should be noted that TSL interception is a perfectly legitimate thing for an employer to do. And since you are probably using a computer provided to you by your employer at work, there are many other ways they could monitor your browsing habits and anything else you do on your computer without relying on a proxy server. So if you want privacy, don't use your work computer or network.

But what about the ISP?

While your employer might have legitimate reasons to do this, your ISP most certainly does not. Fortunately, they can not easily do this. Why? The answer is in your quote:

  If your company has set up the proxy correctly you won't know anything is off because they'll have arranged to have the proxy's internal SSL certificate registered on your machine as a valid certificate. If not, you'll receive a pop-up error message, which, if you click on to continue, will accept the "fake" digital certificate.

Since your ISP does not control your computer, there is no way for them to install a root certificate (other than making you do it). So you would get a warning that the certificate is incorrect every time you visit a site over HTTPS. Not very stealthy in other words.

If you are still concerned someone might have sneaked a root certificate into your trust store, you could used the method above to check. But you would need to compare the certificates you get from the ones from a computer with another ISP, preferably even in another country. Or you could just compare them to the preloaded public key pins for sites that use HPKP.


using network switches to prevent malicious promiscuous mode usage

Promiscuous mode means telling an Ethernet card to record all packets that pass by, not just those addressed directly to it or broadcasts.

If that card is connected to a switch, however, then the switch normally only sends the card packets that are addressed directly to it (or to broadcast), so there's nothing else for the card to see.

I said normally because there are some circumstances where a switch sends other traffic out a particular port:

the switch admin might configure it to do that (e.g. so an IDS can monitor traffic)
the switch might do that if it is having problems (e.g. if it's not sure which port to send a packet to)

So you can't assume that just installing switches makes promiscuous mode go away completely as a threat; a determined attacker might attack the switch to try and make it do one of these things and send her host extra packets she can read with a promiscuous network card.

(And of course a determined attacked will do other things as well, such as attacking other bits of the network to make them send her packets they shouldn't.)

However, switches stop the casual user from using WireShark or Firesheep to poke about on the network; and in any case they offer other advantages, so most network managers have already upgraded to them.


GnuPG/KGpg Sign PGP Key - Sign User ID : What is the difference?

Signatures on UIDs are used to acknowledge trust on other people's identity. If you sign another key's UID, you acknowledge you're sure about this identity.

Signatures on keys are used to bind subkeys and UIDs to your primary key. They're not issued to other keys.

Local signatures are signatures that will not get exported. For example, when syncing a key with keyservers or exporting using gpg --export. They're helpful if

You want to put trust on a key, but not tell anybody about it (eg. you're afraid of government knowing about some relation)
You want to put trust on a key, but aren't too sure about it (eg. for private package repositories -- you will realize when a key changes, but haven't been able to verify it in a secure manner)

OpenPGP/GnuPG trust model: If you want to make use of the web of trust (thus also have GnuPG trust the identities of the "friends of your friends"), you need to give another kind of trust into your friends: trust in their ability and reliability for verifying other's identities. This can be changed by using the trust command in gpg --edit-key.


WPS Why Can't Pin be Bruteforced Offline

The hash of the WPS PIN doesn't leave the router. It is stored on the router.

Client and router perform a Diffie-Hellman key exchange and then use hashes of the PIN and the exchanged keys to prove to each other knowledge of the PIN. The only way to obtain the PIN is to obtain physical access to the router and somehow extract it from its memory.

But that doesn't mean WPS with PIN is secure. Most wifi routers don't rate-limit the amount of PIN entries. WPS pin's are limited to 8 digits of 0-9. That's already weak, but it gets even weaker because the 8th digit is just a checksum calculated from the other 7 and the access point already gives a feedback when the first 4 digits of the pin are correct. That means WPS with PIN can often be brute-forced in about a day.

A more secure variant of WPS is the push-button method where you press a physical button on the router and then have a few minutes to connect new devices. You just need to hope that :

no attacker comes around in that time window and
no attacker gets physical access to your wifi router and
your router actually allows you to deactivate WPS with PIN while still allowing WPS with push-button. Many don't.

Bottom-line: If you want a secure home WiFi network, specifically look for a WiFi router which does not support WPS or at least allows to disable it.


It's an xor cipher with 0x05 as key.

Looking in the ASCII table, the digit 0 is ASCII code 0x30. In binary, that is 110000. Your ciphertext result is 0x35, which is 110101 in binary. The difference is that third-to-last and last positions are flipped (1 becomes 0 or 0 becomes 1). This is indicative of an xor key 000101 (put a 1 in the positions that flip). Converting 000101 (or simply 101 since leading zeroes can be removed) back to (hexa)decimal, you get 5.

The shortcut to calculating the xor key given a ciphertext and plaintext byte, is to xor them together: 0x35 ^ 0x30 = 0x05

To confirm this, we can use any other value from your list:

0 0x30 ^ 5 = 0x35
1 0x31 ^ 5 = 0x34
2 0x32 ^ 5 = 0x37
...
9 0x39 ^ 5 = 0x3c

An easy way to convert between binary / hexadecimal / decimal is python: hex(0b110101) gives 0x35 and bin(0x35) gives 0b110101. Note that the 0b and 0x notations are just prefixes to indicate the number system (binary and hexadecimal, respectively).


Possible to redact information in the clipboard, or to auto-redact when it hits a webpage?

I had some success finding sample tools by doing a search for "clipboard regex". AutoHotKey is a Windows system utility and Firefox has a filtered clipboard plugin available as well.

Additionally, it seems that operating systems tend to make clipboard monitoring a fairly simple task to program, so you could write whatever filters you'd like yourself with relatively minor pain as programming projects go.


Is XSS possible when using htmlspecialchars and https prefix check in href?

When using htmlspecialchars, all HTML tags will be escaped.
So let's say you type in hello.
In source:

Without htmlspecialchars: hello
With htmlspecialchars ENT_QUOTES: &lt;a href=&quot;https://hello&quot;&gt;&lt;/a&gt;.

In browser:

Without htmlspecialchars: hello
With htmlspecialchars: hello


If LDAP credentials are leaked, is IP whitelist still sufficient protection?

There usually is a reason to use more than one way to protect services. Combining credentials with access-lists ensures that one of those can fail without having to deal with an immediate emergency.

That doesn't mean you shouldn't act when one of them gets compromised, why would you have bothered with implementing more than one if you don't care about them?

Technical risks you may have to deal with include misconfiguration of access-lists and IP spoofing. That's why you don't rely just on an access-lists.

However, in my opinion the bigger problem is that the operation expects more than one security measure to be implemented. Someone else may notice a misconfigured access lists and think 'no worries, you still need credentials to use the service'.

Bottomline: if you implement more than one security measure, you need to be sure you can rely on every single one of them. Having more than one just reduces the direct impact of one of them being compromised.


What alternatives are there to the existing Certificate Authority system for SSL?

"Alternatives" depend on whether you want something which may work in the future, or something which works right now, with existing browsers.

Right now, Web browsers expect that servers send X.509 certificates, and then they validate them against the set of root CA integrated in the browser (or operating system). This means that if you want something that works without any extra software installation, then all you can do is alter the set of root CA (your trust anchors). You can:

Remove some of the CA (it has been said that you can remove most of them without really impacting your browsing experience, because not all trusted CA are equally active).
Add new trust anchors. Note that a trust anchor is "a name-and-public-key that you trust a priori". Trust anchors are usually encoded as certificates (because the format is convenient for that), and traditionally are self-signed (mostly because in a certificate, there is a field for a "signature" which cannot be left empty). But you can trust certificates which are not self-signed; you can even trust end-entity certificates (i.e. you trust the specific certificate of a given SSL server: this is called direct trust). With direct trust, you manually manage what you trust with very fine granularity. Note that, with direct trust, you lose the benefits of revocation (a directly trusted certificate cannot be untrusted except by a manual intervention on your part, whereas revocation is about propagating mistrust information automatically).

(One can note that the direct trust model is exactly what SSH follows, and it works well in the usage context of SSH.)

In the future, there could be other models. There are several proposals, some being backed by existing software add-ons. To my knowledge, none has reached the "generally usable" level yet. There are, for instance:

DNSSEC and DANE: DNSSEC is about mapping a PKI on the DNS system, primarily so as to authenticate the data returned by the DNS itself, but this can be leverage to distribute SSL server keys (what DANE is about). This is still a hierarchical PKI, with a limited set of trust anchors; the difference with the existing set of root CA is mostly a change of players: the new set of gatekeepers would be smaller, and only partially overlaps with existing root CA. Also, DNSSEC/DANE binds the process of authenticating Web servers to the DNS infrastructure and actors, and it is not clear whether this is good or bad.
A Web of Trust like OpenPGP does. The WoT model relies on graph superconnectivity. To keep things simple, with a WoT everybody is a CA, and each actor is its own and unique root CA; to cope with gullible or downright malicious "CA", WoT users (i.e. Web browsers) accept a target certificate as valid only if they can verify it through many paths which go through distinct CA and all concur to posit the target server key. The decentralized nature of WoT is very popular among people who distrust governments and anything which looks like an administration. However, WoT security is very dependent on critical mass: it will not give you much until sufficiently many people collaborate. See the Monkeysphere project for an implementation (with browser add-ons)(I don't know much about the project quality, though).
Convergence is a descendant of the Perspectives project. If you get down to it, Convergence relies on Hope and Laziness. What Convergence assumes is that wannabe attackers will find it too hard / expensive / tiresome to actively impersonate a given server with a fake certificate for both a long time and in the view of many people. Namely, practical Man-in-the-Middle attacks are either close to the victim (e.g. users of a given WiFi hotspot), in which case they impact only very few people, or close to the server, which requires something wide-scale (like heavy DNS poisoning) which will be quite conspicuous, hence will not last long. Under this model, Convergence is a nice, relatively inexpensive solution, with only minimal centralization (it still requires notaries, and de facto centralization can be expected, but not as thorough as the current set of root CA).

An important point is that the current system "works". Actual attacks which target the PKI are very rare (much publicized, but still rare). The actual system with roots CA is sufficiently hard to break that attackers find it easier to bypass it through some other ways (foremost of which being abusing the credulity of human users). As such, there is little incentive for replacing it with another system which, at best, will do the same. So, while the alternate proposals have some merit (mostly in financial and political terms), I deem it relatively improbable that any of them dislodges the existing root CA in the near future, for "the Web" as we know it.

For closed architectures which are not the Web, and where you control both client and server, you can use whatever system you want, but closed architecture are precisely the situation where hierarchical PKI work very well.


Is there a website or other resource that lists operating systems/platforms and the included root certificates?

On Windows, CA are normally centralized in the OS, in the "trusted CA" store. Microsoft manages the default contents for this store, and they do this following an explicit "management program". You can find the list of CA there.

Apple also runs a similar program and documents the list of root CA that a brand new OS X will trust by default. Of course, any user is free to alter the list, although most users will keep the defaults.

However, any browser is free to use the OS list, or to use its own. On Windows, Chrome and IE will follow the OS-provided list; on OS X, Safari and Chrome will also follow the OS-provided list. Firefox, on the other hand, has its own list (and, indeed, its own SSL implementation). The list of root CA included by default in Firefox is available on this page. That list applies to all platforms on which Firefox runs.

On Linux, there is no real OS-provided list of trusted certificates (well, there are root CA certificates in /etc/ssl/certs/, but it is unclear whether they are actually "trusted", or simply "known", or which applications use these CA). In any case, Firefox on Linux still follows its internal list; Chromium (on Linux) is documented to use Firefox's list (specifically, to use the same default list as Firefox; local changes to Firefox don't impact Chromium, nor vice versa).

It seems that the Opera Web browser now uses Firefox's list (it relies on the NSS library which handles SSL for Firefox), so it should be considered similar to Firefox (in that respect) on all platforms.

So, for good interoperability, you should choose a CA which is on the lists from Microsoft, Apple, and Mozilla/Firefox. A root CA listed on all three lists will be recognized automatically by the overwhelming majority of users.

I am not aware of any maintained page anywhere which would aggregate these separate lists into a synthetic view. The operational word here is "maintained".

A further complication is that there are two kinds of root CA: the "normal" CA, and the "EV-Qualified" CA. The latter claim to be more thorough in their identity verification; the practical consequences is that their certificates are more expensive, and the padlock icon will be green (or similarly "highlighted") instead of grey. This distinction has attracted some criticism; e.g. Peter Gutmann states that the EV certificates are a trick to raise certificate prices with little security benefit since they don't solve a security issue which really existed in the first place. Yet they exist. If you want the green padlock, you'll need a root CA which is recognized as "EV-Qualified" by the major browsers. You can start with the list from the Wikipedia page.


A website sends account credential field as "empty"

First off, there is the technical explanation that is already covered in the comments: The website seems to use the input type password, not plain text - hence password managers that search for a plain text/password combination fail to recognize this field.

Then there is the wider question of why this would be done.

In this case, this is a bank, which often use your account number (a somewhat sensitive information) as a login name. Using not a plain text field may be to keep (as the comments mentioned) shoulder surfers from peeking your user name.

Yet, this might as well be an attempt on compliance. There are some regulations that do prohibit saving user name/password combination as to avoid problems that might arise from saving passwords:

People tend to forget passwords more often when they do not type then regularly
Malware might extract those saved passwords when they are not handled with care

Those points are not all too valid - the first one even encourages password reuse when no password manager may be used, which is horrible.

The second point is somewhat reasonable with respect to the default setting of most browsers to save such data somewhat unprotected (e.g. without a master password for the vault).

Nonetheless, some regulators do stick to those guidelines and while there exist better ways of complying, this might very well be an attempt of doing so.


Best practices for integrating external javascript?

A chain is only as strong as its weakest link.

So make sure you trust your Content Delivery Network (CDN).  I guarantee it is more difficult for a hacker to penetrate Google's servers than yours.  Cloudflare is another example of a security minded CDN.

Mixed content and Insufficient Transport Layer Security can compromise accounts.  Transmitting any page or script over plaintext can lead to a compromise.   A secure source tag would be src=https://,  nothing else should ever be permitted.


What options are there to clone or image a disk to an encrypted drive?

You can boot into a live Linux CD to do this. The drive encrypted with Bitlocker will be exposed as a regular block device which you can access like any other. If the destination drive is already encrypted with VeraCrypt, you will need to first open it and map it to a block device that you can mount. This can be doing with using a modern version of the cryptsetup utility like so:

cryptsetup open --type tcrypt --veracrypt /dev/sda veracrypt
mount /dev/mapper/veracrypt /mnt

This creates a new block device at /dev/mapper/veracrypt from an already encrypted VeraCrypt filesystem from /dev/sda, and mounts it. Assuming the Bitlocker drive you want to image is located at /dev/sdb, you can then directly copy it to the encrypted block device's mount point as a file:

pv /dev/sdb | tee /mnt/bitlocker.img | sha256sum >/mnt/bitlocker.img.sha256

This will create a bitwise image of the encrypted Bitlocker drive and put it on a file on your VeraCrypt filesystem, while simultaneously generating a SHA-256 hash and writing it to a text file. Make sure to save the hash it generates to a safe place, as it is necessary to use to prove the integrity of the encrypted Bitlocker drive if it becomes necessary.

If you want to copy the Bitlocker image back to the drive, you can write it directly back:

pv /mnt/bitlocker.img > /dev/sdb

Naturally, this will overwrite the drive with the disk image.


Can a Government block a specific app traffic, even with a VPN running?

In theory one could use heuristics to guess the kind of traffic. A typical example is flow analysis where one analysis the size, direction and timing of transferred data because various protocols and applications show different behavior in this regard. But unless one has lots of statistics about the various applications the chance of guessing wrong is high. Also, such traffic filtering is not cheap and I don't think that Turkey has already reached the capabilities of filtering like for example Chinas Great Firewall.

It's more likely that the filtering is targeting VPN in general or is targeting traffic which does not pass through the VPN. Technologies like OpenVPN can be easily detected and blocked by typical ports used or by the format of the exchanged data. But if other applications work through the same VPN it is not likely that the VPN itself is the target because even if it would be possible to detect specific applications it is probably impossible to filter only their traffic from the VPN without affecting the other traffic.

Thus if other applications still work over the VPN it is more likely that you are affected by filters of non-VPN traffic. This can happen if your VPN is not properly setup to include all traffic. Typical problems are that DNS lookups are not done through the VPN or that the VPN only includes IPv4 traffic and IPv6 is sent without VPN. In this case it is possible to target specific application by making their DNS names resolve to the wrong side or by filtering their IPv6 traffic. Also, DNS lookups are cached and it might be that you've tried to use the application without VPN first and that even after switching to VPN it still uses the previous and wrong result of the DNS lookup to reach the server. And even if your DNS lookups are done though the VPN you are affected by DNS based blocks if you still use the ISP's DNS server instead of switching to an alternative DNS server.

And since you've got your IP address and initial routes from your ISP it is maybe possible that the ISP is not only pushing a default route but several specific routes too via DHCP and that these routes are more specific than the routes setup by the VPN. This way traffic for specific networks would not pass through the VPN because it has a more specific route directly to the ISP. This technique of using more specific routes is typically used by the VPN itself but also by attack tools like Poisontap.


How to generate easy to type passwords without sacrificing security?

Mandatory "Use a Password Manager!". But you seem to already be aware of this. Moving on.

There are any number of tricks. In my experience, "easy to remember" and "easy to type" typically means "full English words"; my fingers/brain have a much easier time with words than they do with arbitrary sequences of characters. Two systems that come to mind are:
Diceware
Grab yourself a copy of the Diceware word lists [Article], [large_wordlist.txt] and roll some dice! This list of 65=7,776 unique words was carefully selected to be easy to remember. Wikipedia gives these examples as typical diceware passwords:

conjoined sterling securely chitchat spinout pelvis
rice immorally worrisome shopping traverse recharger

Also: mandatory XKCD advocating passwords of this style.
Passphrase
I'm an advocate that we should ditch "password" from the English language - since it encourages people to think in terms of single words - and with the exception of a few especially moronic banks, all systems accept spaces in passwords now, so why not think in terms of "passphrases"?
A clever trick that I heard of is to set a passphrase that represents some personal-life goal you want to achieve or fact you want to remember. A) since you type your passphrase many times a day, it's a natural reminder to do the thing, and B) once you accomplish the thing, you have a natural reason to change your passphrase! The following would be examples that would naturally want to change after a month or so:

"update $% on my 401(k)"
"get under 10 Smokes/day"
"Sandy's baby due on Aug 24th"
"plan Grampa's 80th b-day party"

[ps. I'm waiting for the flame war on this suggestion. My generic answer: use a longer passphrase!]


How do certificates work in protecting against a man-in-the-middle attack?

the wikipedia article especially the svg image is a good base to start with,

1 fundamental thing you have to understand is that for PKI, it does not matter if everyone has the Public key since you can only use it to ENCRYPT inormation intended for ME with it (its like I give everybody a lockbox only I have the key of)

and the private key can not be deduced from the public key. (cryptographic 'law')


Does DNSCrypt mask/hide the URLs I visit

... whether it's useful to mask/hide from my ISP (Telecom) the HTTP requests I make in my browser.

From the homepage of dnscrypt:

  Please note that DNSCrypt is not a replacement for a VPN, as it only authenticates DNS traffic, and doesn't prevent "DNS leaks", or third-party DNS resolvers from logging your activity.)

Thus the answer to your question is: NO, it does not hide the DNS requests from your ISP. DNSCrypt is not a privacy tool but only prevents spoofing of DNS responses.


No, contactless transactions are not more secure than contact transactions. The whole contactless business has a lot more to do with making payments easier on the point of sale (and possibly enable future developments of the smartcard business) than in increasing security.

Ridiculous early US implementations aside, we have a couple things going on here:

transactions less than a certain amount are authorized in nocvm mode, meaning, no card verification method - it's what you have observed
transactions over a certain amount (depending on the country etc) will be asked for an online pin verification (meaning the PIN is encrypted in the PIN pad and sent over the network to the issuer for authentication), whereas contact-EMV cards will typically do an offline PIN verification where the POS asks the card's EMV chip if the PIN is OK.

this is more of a different kinds of usability tradeoff than a security one - offline pin allows offline authorizations on the POS where transactions need to be super fast. Both online PIN have their unique (and difficult to execute) attack vectors.

with contactless the card doesn't get a chance to verify the issuing host's authenticity (ARPC verification is not done). It's one security measure of the EMV scheme that I never fully understood and with contactless it's gone so I guess I was not the only one :) but still, it's 1 security measure less

Some extra EMV tags aside, as far as I know this is the only impact of EMV+CLESS vs old-school EMV. Magstripe+CLESS, or allowing EMV fallback with CLESS results in that youtube video from the beginning of the post and is completely ridiculous.

EDIT 1: holy cow https://play.google.com/store/apps/details?id=nfc.credit.card.reader.pro2 it seems the ridiculousness is still on. Not only it reveals the card data, but the transaction history too. I mean it's on Google Play, it and a bunch of others. Don't test it with production cards.

I don't understand, Visa/MC went through so much issues on the US market with the early NFC, they went through a mountain of trouble due to early magstripe cards. Finally, EMV is here and it's secure, and then they upgrade it with NFC capability by basically reverting the security almost all the way back to magstripe levels.


How to write a rock solid TOTP implementation?

One may argue that unencrypted secrets, stored "as is" in the database, may be an easy prey to SQL injection attacks. Though conceptually the secrets are anyway accessible from the running server, it may be worthwhile to protect them a bit more, so that attackers will have to go beyond the "custom SQL" stage. For instance, instead of storing the secret S and the rescue code C for each user in the database, store for each user a random value R, and compute the secret S and rescue code C with HMAC over R, using a server-wide secret key stored in a configuration file, not in the database. Use HMAC/SHA-1 over "secret||R" (concatenation of the ASCII string "secret" and the random value R) to get the actual user secret S; for the rescue code, use HMAC/SHA-1 over "rescue||R".

Other people may argue that PHP is not the best language for cryptography. In fact, high-level languages are ill-suited for things like "constant-time comparison functions". To get some real control over implementation issues (all side-channel leaks, including timing), a lower-level language is advisable (even C# or Java would be "lower-level" in that sense).

Blacklisting all submitted codes may increase vulnerability to DoS; someone may spam you with lots of requests so as to make your server remember lots of blacklisted codes. Similarly, your description does not seem to include prevention measures again such heavy spamming. You may want to, at least, refuse to talk to IP addresses which have sent you more than ten requests in the last ten seconds or so.

Implementing cryptography properly is difficult; doing it again means taking extra risks of implementation-related issues. Doing your own code is great pedagogy; but if you want to use the code in production, then maybe you should first try to see if there is no existing implementation which already fits your bill.


I am a bit unclear as to the workflow, so let me know if I'm off.

I believe the situation is that you are communicating with a service. You make a request to the service and it responds, signing the reply with an HMAC. You then verify that the HMAC is correct to ensure both that the request originated from the service (authenticity) and that it hasn't been modified by an intermediary (integrity).

For an HMAC to be effective, the key must be secret. If the key is not secret, then an attacker can perform modify the message or pretend to be the service such that the recipient cannot tell that tell that they are receiving modified messages or not talking with their desired partner. And if you're willing to give up on both integrity and authenticity, there's no point in using the HMAC at all. So, the HMAC key must be secret to be effective.

Exactly what protections are appropriate to keep the key secret is application dependent. For example, storing it in a database table may lead to it getting exposed if your application has a SQL Injection vulnerability. That seems risky to me if you have an architecture that could be vulnerable to SQLi (I would consider any app that takes user input and uses it as part of a SQL query as potentially vulnerable to SQLi). Storing the key in a disk file could be vulnerable to path traversal attack.

In the end, no system will be perfect. You'll have to tune the amount of security to the sensitivity of your application. One trick is to combine multiple security measures by, for example, storing an encrypted HMAC key in the database and storing the key to decrypt it somewhere else (maybe a file outside of your web root). Then an attacker would need to get both the encrypted HMAC key and its decryption key to execute a successful attack. The further you can separate the HMAC key and its decryption key, the more secure you're app will be (and the less convenient it may become to implement and operate).


Network Anonymity is largely how much you perceive yourself to be anonymous. While using a VPN and a layered-browsing method might seem to make you incredibly anonymous, ultimately your connectivity is passing through uncontrolled territory and could be monitored.

Weaknesses of TOR can be found on the wikipedia site: http://en.wikipedia.org/wiki/Tor_(anonymity_network)#Weaknesses

TOR's weaknesses are varied and subject to attack from different vectors. Some involve traffic pattern analysis which can reveal nodes, looking at captured packet data after it exits the TOR (or in your case, the VPN endpoint enroute to it's final destination), and some protocols contain real IP information which could reveal you.

Your VPN, since it is routed through the TOR network, largely serves to conceal your traffic from anyone listening on the TOR network itself. Once it leaves the TOR to the VPN endpoint, some of the TOR attacks become viable. (They probably won't know what is IN the VPN traffic as it is encrypted.) When the traffic leaves the VPN endpoint to it's final destination, it may or may not be encrypted anymore (depending on the traffic), and that data could be used to find out more information. Also, the VPN provider, may keep logs about who and what accesses their network for whatever reason. They can say they don't (some paid ones say so), but you can't ever really be sure. That alone may be a compromise.

Either way, it is a lot of work to put all the pieces of the puzzle together, which is the primary objective in the first place.

EDIT: Oh, one more interesting thing I forgot to mention...
Let's say you had accessed a website with a userID and password before anonymizing yourself, and the connecting information get's logged (IP address, yadda yadda) then you connect to the same website AGAIN later with that same user name and password (but this time from the TOR/VPN combo) the owners/admins of the site could look up that information and identify you almost immediately if they had the inclination to do so.


There is no way to know if what you have downloaded is actually safe. But, a common way to distribute malware are social attacks, where the user itself is downloading and executing the malware and thus implicitly helps the malware to bypass safe guards which are only effective against unintended downloads.

For example it might be claimed that this is an important update or that the software  promises to offer features the user wants (like in the case of cheat software). And sometimes the downloaded software seems to actually do something useful, only that the bundled malware is running in the background unnoticed by the user.


How do you manually encrypt text to an md5 hash?

First of all, let's be clear: encryption (encipherment) and hashing are not the same thing. Hash functions convert an arbitrary-size input into a fixed-size output, which by necessity loses some data and is therefore not reversible. If there isn't any way to get back to the plain text - and there isn't, with a hash function; you might find something that produces the same digest but you can't prove it was the same as the original - then it's not encryption.

Second: you shouldn't be using MD5 for anything, anymore. It's broken. If you don't require security, there are non-cryptographic functions that are faster to compute and produce outputs which are smaller to store/transmit. If you need security at all, use a modern and secure cryptographic hash algorithm, such as a member of the SHA-2 or SHA-3 family.

With that all said: MD5 is an algorithm that operates on bits (although in practice nearly all implementations operate on bytes). There are multiple ways to encode text as bits (binary), most commonly ASCII (which is seven bits per character but widely extended to use the eighth bit of a byte to hold additional values), UTF-8 (each character is stored in one or more bytes), or UCS-2 (or its extension UTF-16, where each character is stored in two - or possibly more, with UTF-16 - bytes).

To hash anything, you take the input (might be encoded text, or an image file, or a network packet data structure, or...) as a buffer, and call the desired hash function with that buffer as an input parameter. For text in particular, you simply take a representation of the text in the desired binary encoding and pass it as the input buffer to the hash function. Every non-toy programming language has some native encoding of text (which may or may not be already suitable for use as a hash function's input buffer), and has functions to convert a text string to a byte array of a desired encoding.

All general-purpose programming languages should also have at least one library that implements the most common hash functions. You can also invoke programs to do it from the command line (or from a shell script), such as md5sum or openssl dgst -md5, although they might not be installed by default on your machine (depending on OS and install configuration).


Is someone able to hack my Facebook account knowing my Dynamic IP, PPPoE and mask?

Your IP is a public address and has nothing to do with your Facebook account. Just knowing it does not help someone to 'hack' you. In the same way, knowing your IP does not increase your threat of your computer being hacked.

He's blustering.


Use combination of digital certificates and symmetric key cryptography

This is how all HTTPS and TLS communications work.

2x Async certs/keys are used to create a shared secret which is used as a symmetric key for the lions share of the communication.

In step 6/7 of this diagram, is where the Symmetric key is created and both sides ChangeCipherSpec to make use of this newly established shared key.


Is mod_reqtimeout a sufficient and safe technique to mitigate Slow HTTP DoS Attacks?

what header, body and minRate settings are considered best practices and what things should we take into account when choosing the values?

This is heavily dependent on the normal use case for your website. You should profile your site and tune to avoid false positives. If you are just hosting small static http content you can safely set these fairly low. If you return large content, have slow servers, have client side code which pump data into a connection as it generates it or expect users on poor connections you need to set the limits in a way to allow for this.

  can enabling mod_reqtimeout potentially impact web applications running on this web server? And, if yes, what possible problems should we expect?

Yes. If a connection fails to meet the restrictions it will be cut and a 408 REQUEST TIME OUT error will be returned. If you set your limits too low this will happen regularly. I would also assume this will happen to a normal user at some point no matter how loosely you set the restrictions. Ideally your application should be able to recover from it (i.e. resend the request or gracefully notify the user there are connection issues).


Generating backup codes for a 2FA implementation

Usually the backup codes are opaque random credentials, not mathematically based on the 2FA seed or anything else known about the user, and generated with sufficient length and entropy as to avoid dictionary attacks.

Treat them like single use passwords- hash them before storage so you don't have the originals; discard after one use in authentication; limit the number of and rate of authentication attempts; and allow authenticated users to generate a new set, which invalidates the previous set.


No, there are no web APIs that an attacker could employ to modify the HTTP version string in a reflected XSS attack.

I often come across similar flaws during penetration testing that are technically XSS, but not directly exploitable without manually altering the HTTP request. These bugs often get rejected by bug bounty programs. Another common example for this type of flaw is the Host header:

Host: vulnerable.example

You would often see that vulnerable.example is reflected in the response body without any filtering but you simply can't choose the value of the host header in a real-life XSS attack, so the vulnerability turns out to be rather useless. Yet another example is XSS via the user agent. Similarly - unless it's a persistent XSS flaw, just printing back a modified user-agent string will most likely not be exploitable.

Beyond reflected XSS there are obviously other vulnerabilities to look out for. The response might be cached somewhere, enabling you to turn it into a persistent XSS flaw. Or the value might be stored unfiltered in some backend logging system.


It is not normal or acceptable behavior  for UI elements to execute user-supplied JavaScript.  Although these bugs maybe difficult to exploit, they need to be patched because running malicious JavaScript means full account takeover.

UI Redress (aka clickjacking) can be used to populate the textbox.  This technique was used to exploit self-inflicted XSS on google.  The X-Frame-Options header element can be used to mitigate this attack.

Self-inflected javascript worms  have spread on Facebook.  Bad guys are always trying to convince the user into doing bad things.  Some users are more than happy to shoot themselves in the foot, the attacker just needs to ask. Facebook has shown us that asking the user to copy/pasting malicious text is enough for a worm to spread.

tldr; fix your damn bugs!