New answers tagged

1

The methodology you are looking at is not designed for penetration testing. From the same url at that website: The aim of system test is to test all of the following areas. Scheduling software Day-to-day operational procedures Backup recovery strategy Management and scheduling tools Overnight processing Query performance ...and.. There are a number of ...


2

George has a good answer with some great information regarding this, however one thing you need to think about with all of this is your user experience, and attack theater. If it's on someone's phone, who would be the one to get that data? Local: A person with physical access to that device. With physical access to the device they can wait to watch the ...


1

I will assume you are using a Strong (slow) Password Hash such as BCrypt with a sufficiently high Work Factor. If you are using a general purpose (fast) hash then the security benefit is very thin. In most cases the Hash should be kept secret. There may be a vulnerability discovered some time in the future. The hash is a multiplier of password strength. ...


0

For me it would feel a little awkward to ask him for a "MasterKey". It does not if the core of the service is to ensure that only that person can access the data by first decoding them. The authentication via an third party is in that case is not useful, you will be better off handing it (correctly) yourself so that the users have only one authentication ...


1

If you are connecting to a service on database-server, that service also needs to listen to a port. Not using an ODBC driver depends on the application at client-side. ODBC is intended to allow several applications (like e.g Word) to make connection to a database. Opening ports of course should be limited as much as possible, but sometimes ain't possible. ...


0

If your application does not require write access to the database consider placing a read-only replica of the database in the DMZ then use an obscure port for the database replication with the "real" database.


0

Another way is to have a reverse proxy also known as load Balancer to act as traffic termination point to external and internal traffic. When traffic gets terminated at a proxy you can inspect the traffic headers and content before allowing it to be reestablished to your servers hiding behind the reverse proxy. To combat web app attacks, you can consider a ...


1

The purpose of the DMZ is to do not expose your DB directly to Internet. Instead you expose it to your web application, and your web application to Internet. But you need to take care of the security of both the web app and the DB. If your web application gets compromised, it doesn't mean that the DB is as well. There are various vectors here, for example, ...


0

I could decipher the characters using ASCII code, I got the following result: [BEL] K [LF] [LF] [LF] [FF] NULL ceuQ \n CI <&NG [SI] [BEL] [BS] [ESC] ( [SO] & " \n E [FS] #' [DC2] [DC4] K [DC1] [BEL], [LF], [FF], [SI], [BS], [ESC], [SO], [FS], [DC2], [DC4], [DC1] are control characters, then it isn't a encrypted text, it's text in hexadecimal. I ...


0

This looks like encoding, not encryption. It is a string of hex codes, likely corresponding to ASCII characters.


3

You are probably looking for xssposed.org, a successor website for xssed.com (actually they imported the old xssed database), and which was renamed to Open Bug Bounty a few months ago. They list XSS and open redirects.


0

You need to know which proxy servers you trust, and which headers to trust (if any) for each of them. For example, you know your load balancer uses X-FORWARDED-FOR so you can trust the rightmost value that is supplied to your web server in this header. Your load balancer will also need to know which IPs to trust. For example, it may trust RFC 1918 private ...


-1

For a desktop application I would prefer password hashing with salt. Hashing with SHA-256 or SHA-1 plus salt seems good. Because Ideally an encryption key for a standalone system as explained above can be obtained by some malicious trick. hashing is a one way street salt ensure some strength, so it isn't so bad


1

As stated in another answer, for proper administration of the server (both from system and DB perspective) the contractors will need to have sufficient levels of access -often root in their respective domains. That said, there are some generally accepted security controls that should be in place in the environment such as: Principle of Least Privilege (...


1

They need to have access to the servers and databases to be able to do their job. For sysadmins they would need the root account, for DBAs they would need the superuser account in the database (not sure what that user is for Oracle, but on MySQL that user is also named root). If you don't trust them, don't employ them, or at the very least monitor them (by ...


0

In nmap, you should know the following: When you want to run a protocol-specific NSE script, such as pgsql-brute (or the generic brute NSE script), nmap will need the version information to match the port or be able to detect it, i.e., nmap -v --script brute -sV -p 5432 <ip> or nmap can skip version detection if the + character is utilized -- thus ...


0

Separating these out may make your system much harder to attack. For example, say there's a SQL injection flaw on your website. The attacker may be able to use SELECT INTO OUTFILE to write a shell to your system. e.g. http://192.0.2.42/comment.php?id=738 union all select 1,2,3,4,"<?php echo shell_exec($_GET['cmd']);?>",6 into OUTFILE 'c:/xampp/...


1

In general, I agree with your implication that if you only have a single web application there is little security benefit to moving the DB onto a separate server. That being said, there could be some contrived scenarios where there might be a security benefit. For example, if the web application does not have full admin rights to the DB, then a compromised ...


0

Performance and scalability is enhanced by deploying it on two servers. I can imagine someone making configuration errors and opening up more ports on the database server. Due to the presence of the firewall this will not lead to a vulnerability easily.


1

I think that the other answers are wrong or at best impractical. In order to protect data in the database and have it accessible only by user request we can do the following. Upon registration of the user we generate two hashes. Hash A: Our password, bcrypt hash, stored in the DB Hash B: Our encryption key, not the same password hash, not stored anywhere ...



Top 50 recent answers are included