New answers tagged

0

In a recent post, I read that Radware found that attacks that last only an hour or less are on the rise – and more than half of the three biggest attacks fell into that category. The implications of these findings are clear. It’s likely that very soon, even long attack campaigns will be based on short bursts of traffic – bursts which are difficult, if not ...


1

A relevant base of the level of trust of an app can be how much of your phone does it needs to access. Some apps require very little access and can do a lot of useful stuff. Some require only needed access, like a flashlight app needing camera access, but many also abuse wanting access to way more than they actually need. It would be illogical for a ...


2

Yes, but don't do it. If you are asking if it is possible to come up with a proprietary scheme for encrypting data that only your application "knows," the answer is yes, until someone figures out how to reverse-engineer it (which is usually easier than you realize). This sort of practice is known as security by obscurity and is highly discouraged. Instead,...


3

The two code snippets will very likely compile to the exact same bytecode, so no difference. Even if it wasn't the case, passwd contains only a reference to the string containing the password, no extra copy of the value is created.


3

There are several ways to do this but basically you are describing something of a digital rights management problem. There are some open-source DRM programs like OpenIPMP which may help but there are probably other ways to solve your problem without using DRM. https://sourceforge.net/projects/openipmp/ You didn't provide a lot of information about your ...


0

Password is something that a user would know, but not necessarily expose. The phone is something that you keep close to you, but it is regularly exposed, sometimes left unsupervised, periodically non-operational. Knowledge can be hijacked\captured when you type it and send your credentials over the network. Phone can be snapped from you in public transport ...


-1

Using a phone is another way of using multi-factor authentication, and certainly enhances security if done correctly. It is not a substitute for a password or other information, but often times authentication uses both "something you have" and "something you know" concurrently to verify, as it mitigates the possibility that either a) your password is stolen ...


2

You should never say never, but there is no reason to believe you could exploit that line to gain RCE. The base64_decode function does exactly what the name implies - it decodes base64. To get the parameter value executed you would need a function that executes code provided to it, like eval. You don't seem to have that, so you are out of luck. With that ...


1

The base64_decode() function is not risky by itself but running arbitrary code on your system is. Having a script that calls system($_GET['cmd']) is almost an invitation for hackers to mess up your server. As soon as anyone skilled finds it, they will have loads of fun at your expense. If you're worried about security in any way, you will never let your ...


3

Others have touched on the classic issues surrounding systems designed by humans for other humans: The reality is laziness and—sometimes—stupidity coupled with “Why would this happen to me?” arrogance. Oh, how many hours of my life have been spent patching systems and—more importantly—fighting with management to get the time/resources allocated to patch ...


4

The root problem The web was simply not designed to allow secure multi-authorship or rich interaction. Nobody talked about separating content from presentation until the late 1990s. By that point, like the QWERTY keyboard, we were basically stuck for no good reason with an existing system. Nobody wanted to "break the web", so mistakes were copied and ported ...


21

It seems easy, but is hard First of all, the attack surface is huge. You need to deal with XSS if you want to display user input in HTML anywhere. This is something almost all sites do, unless they are built purely in static HTML. Combine this with that fact that while XSS might seem easy to deal with, it is not. The OWASP XSS prevention cheat sheet is 4 ...


2

The accurate detection of dangerous security vulnerabilities such as SQLI and XSS during code implementation phase of SDLC is still limited to the type of programming language. Static analysis for such vulnerabilities is most widely done in PHP. Some dynamic methods employ fuzzy techniques during testing or deployment phase. Unfortunately, both ...


32

XSS is a form of code injection, i.e. the attacker manages to inject its own malicious code (usually JavaScript) into trusted code (HTML, CSS, JavaScript) provided by the site. It is similar to SQLi in that it is caused by dynamically constructed code, i.e. SQL statements, HTML pages etc. But while there are established techniques to solve SQLi (i.e. use ...


6

As mentioned in the answer to a similar post of yours (SQL injection is 17 years old. Why is it still around?): There is no general fix for SQLi because there is no fix for human stupidity Developers sometimes get lazy or careless and that causes them to not check the application they are developing. Another popular reason is that the developers aren'...


7

My set of opinion on security and XSS: Rule of programming: You can't know everything. Sooner or later you are going to make a mistake. Rule of programmer: A programmer works 12h a day: 3 is discussing with other programmers random things, 3 is thinking at other things, 3 is discussing on what it should code, 3 it's programming .... projects are made for ...


0

That is incorrect. A hacker can exploit some vulnerabilities like SQL Injection, XSS, LFI, RFI, authentication bypass. He could bruteforce the FTP login or get access via SSH. Or maybe if you had a shared hosting, even if you don't have any vulnerability in your website, a hacker can exploit other websites on the same server and then he could use a ...


1

Certificate Pinning is another commonly used control against Data-in-transit attacks. The TLS handshake never starts if the client doesn't receive a Public Key that is within the client's (the mobile app) known Pin List. I used Cert Pinning as a compliment to payload encryption. Perhaps the following are becoming the base standard for sensitive mobile app ...



Top 50 recent answers are included